GNOME Bugzilla – Bug 539191
thumbnails are computed again and again for larger thumbnail sizes
Last modified: 2009-03-08 00:52:04 UTC
After update to GNOME 2.22 some of directories are displayed after the click, but the nautilus stays in 100% CPU load state and decreases its responsibility (fails to render new directory, scrolling response is very bad). All thumbnails already exist from the previous GNOME version. This problem is 100% reproducible on this directory. openSUSE 11.0, i586 nautilus-2.22.2-30.2 glib2-2.16.3-20.1 jpeg-6b-852.1
+ Trace 200880
Update: Actually, 100% CPU load does not happen forever, but only for several minutes. It computes new thumbnails, redraws window after each thumbnails, but does not save them to ~/.thumbnails. Next time opening the same directory, this behavior repeats again. The problem can be worked around by removing of all thubnails. By returning thumbnails back, the problem appears again.
I can't reproduce this bug on Ubuntu Ibex alpha. It could be something related to an openSUSE patch/configuration (CC-ing Vincent). Also, as the lock seems to happen in some function of the JPEG library, it could be a bug in that code, or a corrupted image on your side. Does this just happen in one directory?
Stanislav, do you have a zoom level set to something different than 100%?
No lock happens. Backtrace was created in random moment. I can do more backtraces in different moments. If you tell me break point, I can test variables there. I can reproduce this problem only in some directories and only if existing thumbnails were created by GNOME 2.18. With fresh ~/.thumbnails dir, there is no way to reproduce it. This bug seems to be a bit fragile to reproduce, but I still have backup of problematic directory and thumbnails. Yes, I have zoom level set to something different than 100%. The window contains ~300 JPEG images from my digital camera. Some of them have orientation tag set (and thumbnails are correctly displayed rotated.) As I wrote above, it is not a lock. Here is my guess, what is happening: 1) Existing thumbnails from GNOME 2.18 are considered as invalid for some reason 2) Nautilus starts to recompute thumbnail 3) Thumbnail is probably correctly recomputed (as there is about 2 sec time between redraws) 4) Thumbnail is not saved anywhere (BUG) 5) Nautilus is signalled to redraw window (small scroll step is visible) 6) Repeat until all thumbnails are "recomputed" (~10 minutes) Next time the window is opened, the process repeats again from beginning.
I forgot to say: During this process, all thumbnail images are displayed from the beginning. There are no "clock icon".
The problem is icon size dependent. It is not visible for normal icon size (or normal icon size - 1 and probably also normal icon size + 1) and starts to be very annoying for normal icon size + 2. Part of images in the directory has rotation tag set. Reproduced with nautilus-2.22.2 openSUSE 11.0 i586. I am able to reproduce this problem with a clean thumbnail directory. How I reproduce: 1) Have a directory with ~500 photos, ~2MB per each (my one is ~/Desktop/foto opened from desktop). 2) rm -rf ~/.thumbnails before starting GNOME 3) Click to desktop icon foto: Window is opened with clock hand icons 4) Wait 10 minutes: All thumbnails are rendered and saved to ~/.thumbnails 5) Close the "foto" window 6) Click to desktop icon foto: Window is opened and instantly renders all icons using correct thumbnails 7) Nautilus starts to re-render icons eating 100% CPU time for several minutes (you can see small scroll bar wobbling about once per second)
> Reproduced with nautilus-2.22.2 openSUSE 11.0 i586. You should upgrade to Nautilus 2.22.4. Some of the thumbnail internals have been rewritten. However, regarding big images: A) large images are not created using gnome-thumbnail, but by loading the original image. This happens in a separate thread, but it is slow and memory intensive. Ideally we'd request larger thumbnails for big images. Side note: IIRC I also speeded up loading of large images in Nautilus 2.22.4 by using the GDK pixbuf loader, and setting the destination size as early as possible B) GDK pixbuf can be easily locked up by scaling a big image down (bug 80925). You are probably seeing this bug.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 523883 ***