Re: F-Spot slow when scrolling 8000+ pictures

["Patrick Wagstrom" <patrick wagstrom net>]

I for one would appreciate that. I'm not a Gnome user, so using the
across-gnome solution that stores too much data and slows down F-Spot
is rediculous for me. Here, you have your first patch tester.

The thumbnail issue is not GNOME specific.  GNOME implements the draft freedesktop.org standard for thumbnail management.  KDE also is working toward the same goal.  For more information on the spec of thumbnail management please see:

http://jens.triq.net/thumbnail-spec/index.html

Also, having F-Spot create it's own thumbnails not only duplicates data on disk if you have another program (Nautilus, Konquerer, EOG, whatever) that creates the thumbnails, but adds additional code complexity to the program.

Finally, with regards to the people having the issue with the number of files in a directory, the spot where that is slow is in a directory read and a file lookup.  However, a quick look at most filesystem code will show that lookup is quite speedy, often using a hash, so the increase in time for accessing a file when there is one file or 50000 files in a directory is small.  However, where the increase will occur is in reading in all those thumbnails, any way you slice it, that's a LOT of data.  As the thumbnails are saved, at least it won't have to read in the complete image every time there is a change.

Anyway, read the spec, it's a little enlightening to some of the design rationale.

--Patrick