After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 104224 - Nautilus appears to do blocking io when loading thumbnails for images
Nautilus appears to do blocking io when loading thumbnails for images
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Thumbnails
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: Christian Neumair
Nautilus Maintainers
: 142361 165344 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-01-23 13:50 UTC by Dave Bordoley [Not Reading Bug Mail]
Modified: 2007-09-10 20:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
script to create folders with files to test thumbnailing (1.65 KB, text/plain)
2006-11-01 19:41 UTC, jdo
  Details
Proposed patch (22.80 KB, patch)
2007-09-02 09:57 UTC, Christian Neumair
rejected Details | Review

Description Dave Bordoley [Not Reading Bug Mail] 2003-01-23 13:50:53 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.
Comment 1 Mark Finlay 2003-02-07 18:22:31 UTC
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.
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2003-02-07 18:38:47 UTC
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.
Comment 3 Matthew Gatto 2004-11-06 08:12:37 UTC
*** Bug 142361 has been marked as a duplicate of this bug. ***
Comment 4 Jason Tackaberry 2005-05-03 12:15:36 UTC
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.
Comment 5 Martin Wehner 2005-06-20 22:31:23 UTC
*** Bug 165344 has been marked as a duplicate of this bug. ***
Comment 6 Gregory S. Hayes 2005-12-12 10:43:31 UTC
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. 
Comment 7 Vidar Braut Haarr 2006-01-11 11:20:16 UTC
(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.
Comment 8 jdo 2006-11-01 19:41:25 UTC
Created attachment 75790 [details]
script to create folders with files to test thumbnailing
Comment 9 jdo 2006-11-01 19:45:16 UTC
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
Comment 10 Christian Neumair 2007-09-02 09:57:27 UTC
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.
Comment 11 Christian Neumair 2007-09-02 09:59:58 UTC
Patch nag on mailing list, possibly with followup discussion:
http://mail.gnome.org/archives/nautilus-list/2007-September/msg00002.html
Comment 12 Christian Neumair 2007-09-10 20:11:03 UTC
Another patch using async I/O has been committed. Closing.