GNOME Bugzilla – Bug 430618
gThumb unresponsive during thumbnail generation
Last modified: 2009-10-08 15:40:09 UTC
gThumb becomes unresponsive during thumbnail generation. This is particularly noticeable for raw images, which are very slow and compute-intensive. I don't know how to fix this. Is it possible to make thumbnailing a "low priority" process? - Mike
Related report: http://bugs.launchpad.net/ubuntu/+source/gthumb/+bug/104893
Maybe it would improve the impression if thumbnail generation started with the displayed images instead of the bottom ones. In fact, why bother generate thumbnails for images not yet shown? Maybe also extracting EXIF thumbnails where available instead of generating them would speed things up? // Joakim
(In reply to comment #2) > Maybe it would improve the impression if thumbnail generation started with the > displayed images instead of the bottom ones. In fact, why bother generate > thumbnails for images not yet shown? Thumbnail generation does start with the displayed images, then it goes back and starts thumbnailing the remaining (non-visible) images in the folder. This is slow at first, but once it is done scrolling through the images is much faster. I think this is a good trade-off (I've tried it both ways), but it would be better if the gui remained highly responsive during thumbnailing. The RAW thumbnailing mode has been much improved; it is much faster now (bug 431483) because it does use the raw-embedded thumbnails. > Maybe also extracting EXIF thumbnails where available instead of generating > them would speed things up? Maybe we should experiment with that; I'm not sure. One concern is that some editing programs modify the image but do not update the embedded thumbnail properly, so we can not be 100% certain that the embedded thumbnail is correct. (For example, gThumb had a bug where it did not update the rotation tag for the embedded thumbnail.) Thoughts? - Mike
(In reply to comment #3) > (In reply to comment #2) > > Maybe it would improve the impression if thumbnail generation started with the > > displayed images instead of the bottom ones. In fact, why bother generate > > thumbnails for images not yet shown? > > Thumbnail generation does start with the displayed images, then it goes back > and starts thumbnailing the remaining (non-visible) images in the folder. This > is slow at first, but once it is done scrolling through the images is much > faster. I think this is a good trade-off (I've tried it both ways), but it > would be better if the gui remained highly responsive during thumbnailing. It appeared that the catalogs I entered had EXIF data set to 0000:00:00 00:00:00 because the camera used had not had its clock set. So all images where resorted for each thumbnail generated or something. I did not see the thumbnails until all were generated or close to because they had the same EXIF date and I had EXIF sorting turned on. > The RAW thumbnailing mode has been much improved; it is much faster now (bug > 431483) because it does use the raw-embedded thumbnails. Cool, I'll try it out. > > Maybe also extracting EXIF thumbnails where available instead of generating > > them would speed things up? > > Maybe we should experiment with that; I'm not sure. One concern is that some > editing programs modify the image but do not update the embedded thumbnail > properly, so we can not be 100% certain that the embedded thumbnail is correct. > (For example, gThumb had a bug where it did not update the rotation tag for the > embedded thumbnail.) Thoughts? I think we should scrap them if we can't trust them. // Joakim
Correction: When having EXIF sorting turned on the thumbnail generation is disregarding which thumbnails is visible in the index. I report it as a new bug. // Joakim
Joakim, If you have a chance, please test the patch at bug 450241 to see if it makes the UI more responsive during thumbnailing. - Mike
Yes, when I got my dev computer back from bitheaven, right now it is a pile of concrete, so maybe during the weekend. Anyway, from the bug 450421 I can confirm that there is something fishy about browsing folders with videos. It makes the EXIF sorting very confused and similar to heaving a lot of scanned images with no EXIF meta data in them at all. // Joakim
As soon as there are videos in the directory, thumbnailing gets very slow and with it, ghtumb gets unresponsive.
Closing this as obsolete, due to the rewrite in ext branch (http://live.gnome.org/gthumb). - Mike