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 340563 - EOG caches all images in directory when only 1 is selected
EOG caches all images in directory when only 1 is selected
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: image viewer
2.14.x
Other Linux
: Normal major
: ---
Assigned To: EOG Maintainers
EOG Maintainers
eog-ng
Depends on:
Blocks:
 
 
Reported: 2006-05-03 20:59 UTC by Kevin D. Knerr, Sr.
Modified: 2007-12-17 10:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Description Kevin D. Knerr, Sr. 2006-05-03 20:59:57 UTC 
cf https://launchpad.net/bugs/37429

If 2 or more images are selected, EOG only caches the selected images. If only 1 image is selected, EOG caches "every" image in the directory.

This behavior is exhibited whether the selection is specified via Nautilus or command line. (Also, when specifying via command line, if a wildcard pattern is used that resolves to a single file, EOG still caches every image.) No collection options are in use.

In a directory with hundreds of images, this behavior makes EOG extremely slow to respond and consumes vast amounts of memory. Under the right combination of circumstances (less available memory, many images in directory) EOG will consume all available memory, making the system completely unresponsive.

I've confirmed that this behavior is present in at least Ubuntu Breezy and Dapper.
Comment 1 Lucas Rocha 2006-07-13 18:19:08 UTC 
Thanks for the report! Unfortunately, this is not exactly a bug it's design problem: to make it easier to navigate through images from the same directory, EOG all images thumbnails even when they are not visible. This indeed makes EOG consume lots of memory and repond slowly. However, this problem has been already solved in eog-ng branch with some on demand thumbnails loading which means EOG uses much less memory and is quite faster.
Comment 2 Lucas Rocha 2007-03-18 00:06:45 UTC 
eog-ng branch, which has a full rewrite of eog's core, has been merged into trunk as part of 2.19/2.20 development cycle. Therefore this bug is fixed now. Thanks for the report!
Comment 3 Barry Kelly 2007-12-17 10:25:59 UTC 
Opening an image in a directory with 100000+ image files in it is still excruciatingly slow.

Also, eog doesn't seem to load the next image while viewing the current image - if the next image is multi-megabyte, there's an unacceptable pause before the next image comes up.