GNOME Bugzilla – Bug 104224
Nautilus appears to do blocking io when loading thumbnails for images
Last modified: 2007-09-10 20:11:03 UTC
I have a folder with about 120 images in it. When I open this folder nautilus loads nice thumbnails for the images, which takes a while, however while it is doing this it is impossible to interact with other nautilus folders because it appears to be doing blocking io.
I cannot see this in 2.2. Opened up a folder and it began thumbnailing, but my other nautilus windows and the deaktop were grand.
This is still a problem and I have talked to alex about it. While the actually thumbnailing code uses threads, loading already existing thumbnails doesn't. This is also mentioned in some of the nautilus docs in cvs. However this is somewhat of a minor bug because its only visible when loading a large number of image thumbnails.
*** Bug 142361 has been marked as a duplicate of this bug. ***
Problem still exists with Nautilus 2.10.0. It's true that it's only visible when loading a large number of thumbnails, but for certain definitions of large. For example I store my images on a file server and access them over NFS via my wireless network, which isn't very fast. (Well, it's not very slow either -- 2MB/s, ~2ms latency.) Loading a directory with 500 pre-generated thumbnails takes 10 seconds, during which time all of Nautilus is frozen. (Note this is only an issue if the thumbnails are pre-generated. When Nautilus first generates thumbnails for a directory, it does this asynchronously and all is well.) I'll grant you that accessing directories of images over a wireless network isn't a mom-and-pop use-case, but it's also not that obscure. And 500 files is not a large number of images these days.
*** Bug 165344 has been marked as a duplicate of this bug. ***
This is another leg of a _very_ critical issue. The following bugs: <a href="http://bugzilla.gnome.org/show_bug.cgi?id=169867">169867</a> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=104224">104224</a> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=150483">150483</a> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=304184">304184</a> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=141073">141073</a> combine together to create some nasty behavior for the user: 1. Open directory containing a large number of "thumbnail-able" files. 2. Watch as all I/O to open nautilus windows stops. 3. Discover there is no way to "stop" what is going on except by closing the window (which probably won't respond), killing nautilus, or exiting the session. 4. Due to the "memleak" behavior, observe your memory get soaked up (even if you do manage to close the window without killing nautilus.) Imagine the pain of trying to wait through minutes of no I/O with any nautilus window just because you want to decend into a subdir of a directory with lots of images. With no "location bar" in the default spatial mode it presents a terrible problem. Trying to circumvent the issue by moving out all the images into subdirs will reveal that, since the .thumbnail cache is never "managed", the old thumbnail files are duplicated the next time you view their new location. In addition to "not managing" the stored thumbnails, the cache itself is never cleaned up. Mine was >2G! I hope you can work together with us in the community to fix this outstanding critical issue. Please let us know if there is anything we can do to help get the ball rolling. There are even a few patches out there on some of these bugs that probably have neven been looked at :( I personally think improvements in this area would be highly visible, as it certainly must effect the performance and usability for a number of others.
(In reply to comment #2) > However this is somewhat of a minor bug because its only > visible when loading a large number of image thumbnails. It's not "minor" at all. I'm guessing "most people" nowadays have digital camera, like my parents do. After a while, you start building up a significant library of images. The largest single folder in my parents collection is the summer vacation one, with over 600 images. Loading this folder in: Nautilus (thumbnails already generated): ~180 seconds. Thunar (XFCE file-manager): 2 seconds. gthumb: 2 seconds. Naturally, since the entire desktop freezes during this period, AND you get the "This application is not responding"-dialog, my parents just usually reboot the computer and deem that things crashed.
Created attachment 75790 [details] script to create folders with files to test thumbnailing
I want to add some extra information. A folder with more than 1000 PNG or TIF files could taken more than one hour. These are test result, using the attached script file to generate two folders with PNG and JPG files Test for timing when switching between the two folders. 500 jpg files icon view 4 seconds 500 jpg files list view 4 seconds 500 png files icon view 54 second 500 png files list view 78 seconds Test for timing with 'reload' button 500 jpg files icon view 1 second 500 jpg files list view 1...4 seconds 500 png files icon view 1 second 500 png files list view 75 seconds Nautilus: 2.16.1 OS: Ubuntu Edgy CPU: AMD Athlon Thunderbird 1400 jdo
Created attachment 94801 [details] [review] Proposed patch The attached patch implements multithreaded thumbnail loading using two worker threads. It also implements an algorithm which resizes the thumbnail preview image to the expected thumbnail size, so your icons won't jump around that often. Unfortunately, it makes the nautilus-icon-container explicitly call NautilusFile-related functions, and seems to bloat the NautilusIconFactory API somewhat. if this is a problem, we can also move more of it into FMIconContainer, but I wanted to keep the patch size reasonable and I think it's a purely aesthetic issue.
Patch nag on mailing list, possibly with followup discussion: http://mail.gnome.org/archives/nautilus-list/2007-September/msg00002.html
Another patch using async I/O has been committed. Closing.