Re: GQview 2.0.2 and 2.1.2 released.

Greg Troxel wrote:
> I've updated pkgsrc/graphics/gqview-devel and it builds and runs ok on
> NetBSD-current (i386).
> 
> I have two odd behaviors:
> 
> Starting up gqview in an empty directory takes a lot of CPU time.  I
> immediately hit ^Q when the window appeared.
> 
> gdt 28 ~/FOO > time gqview 
> GQview 2.1.2, This is a beta release.
> 
> (gqview:552): Gdk-WARNING **: shmget failed: error 12 (Cannot allocate memory)
> Unable to write history lists to: /home/gdt/.gqview/history
> 
> real    0m6.447s
> user    0m5.301s
> sys     0m0.531s
> 
> This did not happen to me with 2.1.1.

I am unable to find anything that might cause a longer startup time. Going 
through a diff between the two releases, if you are using the tree view for 
folders this change in view_dir_tree.c:

@@ -1292,7 +1292,7 @@
         g_free(vdt->path);
         vdt->path = g_strdup(path);

-       fd = vdtree_populate_path(vdt, vdt->path, TRUE, TRUE);
+       fd = vdtree_populate_path(vdt, vdt->path, TRUE, FALSE);

         if (!fd) return FALSE;

is the only change in 2.1.2 that is behavioral (the only one that possibly 
effects the code path on start-up). The only other suspect would be a 
botched fix for gcc 4 compiler warnings (all were signedness warnings).

If you use the folder tree view, check by toggling it off and see if the 
start-up problem goes away.

Is the shmget and history list problem new too? (if so probably a symptom 
of the cause of the slow startup.)

> The other problem is that I have thumbnails set to cache thumbnails,
> not to use shared thumbnail cache, and to use .thumbnails.  For
> various reasons, I don't want thumbnails left in my home directory,
> particularly when viewing images that are in a different filesystem.
> (In general, I think it's a security bug to leave a thumbnail in a
> different filesystem.)  The pan view seems to object to this.  It
> would be nice if it used the same thumb size as was normally
> generated.  I suspect the problem here is that the
> .thumbnails/image.jpg.png format doesn't have a way to store multiple
> sizes.

The problem is the design of the original GQview thumbnail caching 
mechanism, it will always regenerate a cached thumbnail when it does not 
match the requested size. The 'shared thumbnail' design always uses 128x128 
and 256x256 thumbnails on disk, and scales down internally when needed 
(plus both the large and small size can coexist).

The pan view needs to be able to easily switch between a variety of 
thumbnail sizes. To avoid constant regeneration of the 'classic thumbnail' 
cache it will not use it.

> Perhaps a reasonable solution would be to have an option to decline to
> store thumbs in ~/.thumbails or ~/.gqview/.thumbnails for images on a
> different filesystem, falling back to .thumbnails in the image
> directory in that case.

As stated above the pan view's issue is not where the thumbnail cache file 
is stored, but the poor design of the classic caching mechanism when the 
requested thumbnail size changes often.

Greetings,
John


-- 
John Ellis <[email protected]>

http://gqview.sourceforge.net <GQview> | http://hideseek.sourceforge.net
http://gqmpeg.sourceforge.net <GQmpeg> |     <Preferences Hide and Seek>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642