GNOME Bugzilla – Bug 515250
EOG slow, locks up system on bitonal TIFF
Last modified: 2008-02-11 18:52:20 UTC
This bug has been reported here: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/189048 "Some types of bitonal TIFF images load very, very slowly, causing the entire system to slow to a crawl and in some cases lock up Gnome completely requiring switching to a different terminal and rebooting. The images are not that big, around 5 MB. System is a dual-core intel @ 3.40 Ghz and 1 GB RAM. The same images open up fine on a slower machine (2.8 Ghz P4 / 512 MB RAM) using windows XP and acdsee 8." sample image: http://launchpadlibrarian.net/11759926/test_img.tar.gz Thanks,
Trying to open that image with several other gdkpixbuf based viewers, and also trying to thumbnail it with nautilus, caused a *huge* memory usage. This is most likely a problem with the GdkPixbuf TIFF loader.
So, there is something to notice. Opening that image in a newly created directory causes eog to use *twice* as much memory, as what it would need when opening the image if this has already been thumbnailed. Test case: 1. mkdir testdir/ && cp 00019.tiff testdir/ 2. Run eog testdir/00019.tiff 2.1 This causes eog to use about 270 MB of memory to load the image *before* the image icon appears. 2.2 EOG tries to load the image icon with gnome-thumbnail, as the thumbnail doen't exist, gnomethumbnail needs to open the image and create it. This causes eog to use about 270 MB extra. 3. The image icon appears, and eog is using about 550 MB. That image doesn't get released. 4. Close eog. Second test case. 1. Open eog in the same way, now that we knwow that the image thumbnail already exists. 1.1 Eog uses about 270 MB of memory. 1.2 EOG tries to load the image icon, gnome-thumbnail finds it ~/thumbnails, and loads it from there. 2. The image icon appears, and eog is using *only* 270 MBs. 2. You can close eog.
Created attachment 104735 [details] massif output for the first test case
Created attachment 104736 [details] massif output for the second test case
Created attachment 104755 [details] [review] Use loaded pixbuf to create thumbnail eog-thumbnailer.c is based in nautilus. There, it makes sense to always use an URI to create thumbnails. In eog, however, sometimes we already have the pixbuf loaded in memory, and in these cases, asking gnome-thumbnail to load the pixbuf in order to create the thumbnail wastes memory and bandwidth. This patch improves this situation. If we can't find a thumbnail but have the pixbuf already loaded, use it to create its thumbnail and save it, instead of asking gnome-thumbnail to load it again.
Created attachment 104756 [details] massif output for the first test case after the patch Here we can see that eog needs *only* 280 MBs, instead of 550 MB, after having applied the patch.
I reported a very similar bug a while back: Bug 160460. It is closed now but there is some useful information and cross-refs to other bugs there.
I gave your patch a try and it seems to work fine. :)
Committed in trunk (rev. 4350). I'm marking this as fixed as I don't see further improvements on the application side (see bug #57183 for reference): 2008-02-11 Claudio Saavedra <csaavedra@alumnos.utalca.cl> * src/eog-jobs.c: (eog_job_thumbnail_dispose), (eog_job_thumbnail_new), (eog_job_thumbnail_run): * src/eog-jobs.h: * src/eog-list-store.c: (eog_job_thumbnail_cb), (eog_list_store_add_thumbnail_job): * src/eog-thumbnail.c: (create_thumbnail_from_pixbuf), (eog_thumbnail_load): Load thumbnail from EogImage instead of GnomeVFSURI. * src/eog-thumbnail.h: * src/eog-window.c: Use the pixbuf data in EogImage to create a thumbnail if this exists and thumbnail under ~/.thumbnail is not valid/doesn't exist. Improves performance and memory usage. Fixes bug #515250.