What I believe is the main cause of this bug has been discovered. Details are in a comment I left on the GNOME bug report.
Briefly, the issue is that in scanned PDFs, each page contains an image. Evince, unlike simpler viewers, allows users to copy images. Problem is, the images are prepared in advance when the page is loaded. On a scanned PDF, the images are of the size of the _original_ scanned page. In an example PDF here, each such page is 4000x4000 pixels, which means 64 MB per page. Caching 4 pages in addition to the current one means over 300 MB of RAM is used - very problematic (the actual pages, rendered at say 1024x786, should only take around 4 MB each, for 20 MB overall). I again reiterate that I believe the severity of this bug should be higher than 'low'. It is unclear how GNOME will respond. A correct solution would only prepare the images for copying only when an actual copy request is made, but this necessitates various changes, including to Poppler and perhaps other rendering backends as well for the other formats aside from PDF. Meanwhile, if this is not solved in time for Hardy, I suggest that Ubuntu consider disabling image copying in Evince, especially since Hardy is an LTS release. I attach a tiny patch that does so. The only functionality lost is that one cannot copy images by right clicking or dragging them, which is probably a rare behavior anyhow (and one can of course still take a screenshot and get the desired part out of it). The advantage is that Evince will not have unacceptable memory behavior on certain PDFs. On my example PDF, patched Evince uses 38 MB instead of over 300 MB. ** Attachment added: "no_image_copying.diff" http://launchpadlibrarian.net/11146014/no_image_copying.diff -- memory leak in evince? https://bugs.launchpad.net/bugs/132612 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
