Re: GQview 2.0.2 and 2.1.2 released.

  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:


Thanks for looking.  I'm not using the tree view.  I noticed that
other programs were also being slow to start, and it's only because
gqview is normally so speedy that I noticed.  It turned out to be yet
another fontconfig cache file lossage problem, and I rebuilt
fontconfig and did 'fc-cache -r -v' to blow away all cache files and
recreate them.  Now it's pretty fast, hitting ^Q in a directory with 5
2.6 MB jpegs that already have thumbs:

> time gqview 
GQview 2.1.2, This is a beta release.

real    0m0.611s
user    0m0.302s
sys     0m0.098s

  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.

OK.  Perhaps this should be clarified somehow, but I'm not sure where.
It seems there are really only two mechanisms, the freedesktop.org
shared cache, and the gqview mechanism.  The gqview mechanism can
either use .thumbnails or e.g.
~/.gqview/thumbnails/full/path/to/image-basename.jpg.png but it's the
same file format and sizeissues.  Is that right?

Then, the other question is reading thumbs.  I currently like having
thumbs in .thumbnails because I make them on one machine and then
rsync my images.

  > 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.

Sure -- what I meant by bring that up was that currently I entire
disable shared caching because it violates my security policy when it
does cross-fs caching.  If there were an option to only put things in
the shared cache if they were on the same filsystem, then I could
enable it and the pan view would work reasonably on most images.

(In my view the freedesktop.org spec is flawed from a security view
and should be changed to allow in-fs caching.  But I'm not trying to
push that here.)

    Greg Troxel <gdt-2FjktZCtrC/[email protected]>

-------------------------------------------------------------------------
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

_______________________________________________
Gqview-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gqview-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iD8DBQFFNhri+vesoDJhHiURAnruAKC1yERvR73KVWplQyE4mA/SdgroAwCgkvJ1
ttQOPNQ3QCy3jh+6Q0HtN0A=
=XO9t
-----END PGP SIGNATURE-----