RSS/Atom feed Twitter
Site is read-only, email is disabled

Fwd: some comments about the Thumbnail Managing Standard 0.5

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Fwd: some comments about the Thumbnail Managing Standard 0.5 Sven Neumann 17 Apr 02:20
  Fwd: some comments about the Thumbnail Managing Standard 0.5 Rapha 17 Apr 10:46
Sven Neumann
2002-04-17 02:20:26 UTC (about 22 years ago)

Fwd: some comments about the Thumbnail Managing Standard 0.5

Hi,

as you might know we are implementing the proposed Thumbnail Managing Standard for GIMP 1.4 (see http://triq.net/~pearl/thumbnail-spec/). Mitch and me have sent this mail to the free desktop mailing-list today. I'm forwarding it here just in case someone wants to join the discussion...

Rapha
2002-04-17 10:46:37 UTC (about 22 years ago)

Fwd: some comments about the Thumbnail Managing Standard 0.5

On 17 Apr 2002 02:20:26 +0200, "Sven Neumann" wrote:

Mitch and me have sent this mail to the free desktop mailing-list today. I'm forwarding it here just in case someone wants to join the discussion...

Lots of good points in your message. But I disagree with the following suggestion:

We also think that the thumbnails should be split up into subdirectories in order to avoid problems with too many files in one directory. A typical user might nowadays easily have several thousands of thumbnails. Most filesystems don't cope well with such large amounts of files in one directory. Our proposal is thus to introduce subdirectories specified by the first letter of the thumbnail name. That would give 64 subdirectories and the thumbs should evenly distribute between them. So, for example a 128x128 sized thumb for ~/photos/me.png would be stored into ~/.thumbnails/normal/c/c6ee772d9e49320e97ec29a7eb5b1697.png

Creating subdirectories should only be recommended if a (very) large number of thumbnails are expected. But in many cases, this should not be done, because it would have a negative impact on the performance (and waste some inodes, but that is less important).

At work, my home directory is mounted over NFS. I have learned to reduce the number of sub-directories as much as possible, because if I do a "find", then a single large directory will usually be processed faster than multiple smaller subdirectories. The large directory will be stored in the local NFS cache and can then be processed faster than the separate subdirectories that will require additional NFS requests.

So I do not think that forcing all users to have 64 additional directories is a good idea. It would make sense in some cases, but not always. My first thought was to make this configurable so that each user could choose the most appropriate setting depending on his/her environment (and number of thumbnails expected), but this it not easy to do if many programs are involved. Maybe the programs should accept both ways of storing the thumbnails (with or without sub-directories) and check for both when they are trying to see if a thumbnail exists for a specific image. This adds some complexity to the standard, so there are pros and cons for this idea.

-Raphaël