GNOME Bugzilla – Bug 584863
eog uses too much memory
Last modified: 2012-11-20 21:41:14 UTC
Please describe the problem: eog trys to open very large images. If the image is too big, the system is just swaping, and it is hard to stop it. possible solutions: - eog should not open very large images - eog could create carefuly a scaled small version of the image, and shows the scaled down version Steps to reproduce: 1. open a very large image in eog 2. 3. Actual results: system is swapping, it is hard to close eog to get the system in a useable state Expected results: eog shows the image without swapping, or aborts with an error Does this happen every time? yes Other information:
Not sure what we can do about this. It's hard to determine an image's size in advance (filesize is not reliable) due to fileformat restrictions and the way gdk-pixbuf works. Scaling AFAIK requires loading the full image once anyway, too. I think it's also hard to explain to the average user why he only gets a lo-fi variant of a picture. How large are your images that they make your system swap? 1 GB of RGB is roughly 20000x20000px (a little less).
It's also possible to load a scaled version of an image with gdk_pixbuf_loader_set_size () in response to the GdkPixbufLoader::size-prepared signal. Still, I would make this very optional or only do it when it is obvious that the image size is ridiculously big (users could be warned about this beforehand).
In case of SVG image, the image which is got through GdkPixbufLoader is not reliable when the image is zoomed in or out, so I am in favor of the use of gdk_pixbufloader_set_size.
Reopening as I can't see any open non-developer question.
gdk_pixbuf_loader_set_size won't help here I think. It's AFAIK scaling the image after having loaded it. So, if the unscaled image is making you swap, it will do just the same in this case (even more so as the scaled image simultaneously needs additional memory). Also, what do you do if you modify the (then scaled) image and save it? You would have to reload it unscaled -> swapping. Regarding SVGs: If everything goes by plans we'll draw them without using the pre-rendered variant as a placeholder during filtering soon (bug 626795). I'd say this is more or less a CANTFIX.
Maybe it is possible to limit the amount of data memory for a single eog instance?
Hello, I have a similar problem with animated gif. When I open a 16.8Mo GIF, GwenView uses 37Mo while eog uses 920Mo of memory! So I have regular swap or crashes for bigger animated GIFs (sometimes I build GIFs > 50 Mo .... don't ask me why ^^). I looked for a solution (except openning them with GwenView) but I did not find anything usefull on google so I try here. Is it already reported? Is there a way to fix it? My version of eog is 2.32.0 on Ubuntu 10.10. I tried on another PC which is also on Ubuntu 10.10 and the result is similar. Thanks
This bug was reported against a version which is not supported any more. Developers are no longer working on this version so there will not be any bug fixes for it. Can you please check again if the issue you reported here still happens in a recent version of GNOME and update this report by adding a comment and adjusting the 'Version' field? Again thank you for reporting this and sorry that it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE after 6 weeks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!