Bugzilla – Bug 15945
ImageViewer: showing large images can lead to out of memory situations
Last modified: 2016-11-27 21:01:38 UTC
I've encountered situtations where fab4 would have killed embedded SBS while the ImageViewer screensaver was running. This mostly happened with large pictures (photos, 6 megapixels and more), when the interval was set to some short value. It seems the garbage collection didn't have time to clean up the memory in between image retrieval/resizing, leading to out of memory situations. Forcing garbage collection whenever an image has been rendered seems to improve memory usage. While there are still spikes when the image is loaded, the memory is quickly freed, bringing the level down to normal load. Without the immediate GC fab4 might run out of memory trying to resize the next image before the memory has been freed..
Created attachment 6693 [details] trigger forced garbage collection after an image has been rendered
Created attachment 6694 [details] force garbage collection after image has been rendered previous patch included other (unrelated) changes
FWIW: it took longer with this patch applied, but eventually crashed all the same.
== Auto-comment from SVN commit #8667 to the jive repo by mherger == == https://svn.slimdevices.com/jive?view=revision&revision=8667 == Bug: 15945 Description: don't zoom image unless needed
Created attachment 6697 [details] File causing massive memory consumption Further investigation showed that the problem described is limited to _some_ images. Attached is a sample file which will cause a memory consumption of >10MB when loading using Surface::loadImage(). Obviously the underlying code isn't able to only get a subsample of the jpg data. Interestingly the same file doesn't have EXIF and other headers neither. Unfortunately I can't remember how I created it. I ran another test on an SD card full of 10/14 megapixel pictures (directly from the camera), and I didn't see any of the spikes as seen with the above much smaller sample file.
The problem I'm seeing is due to the images being saved as progressive JPEG. If I take the same file and save it without the progressive flag, it would load easily without the additional overhead. I didn't find any reference to this being an issue on the internet, but I've seen it with all my progressive JPEG files. The bottom line probably is: we're tight on memory. Image handling requires a lot of it. Thus we're prone to problems in this area. I'd expect the same or similar issues with anything else than jpg, as afaik only jpg offers the optimized scaling. The good news is: most people probably will use their images as taken with their camera. No fancy progressive encoding used, jpg only. Some help with garbage collection might still be good, though expensive. I'll run a few more tests with it to see whether it would negatively influence playback.
*** Bug 15977 has been marked as a duplicate of this bug. ***
Created attachment 6730 [details] Mickey's log file from his oom crash
Created attachment 6733 [details] Photo 1 from bug 15977
Created attachment 6734 [details] Photo 2 from bug 15977
Comment on attachment 6734 [details] Photo 2 from bug 15977 I used Nikon Capture 4.3 software to resize. Original probably 4-6MB.
Pictures look fine if fab4 is given enough time to do the garbage collection. What image change interval are you using?
Andy - do you know whether your new resizing code would improve the behaviour with progressive JPGs?
No, progressive JPEGs are evil, my resizing code can be set to ignore them because they waste so much memory. We should just skip or display an error message for prog JPEGs.
How would I be able to get that piece of information from the Lua side of SP?
== Auto-comment from SVN commit #9507 to the jive repo by mherger == == http://svn.slimdevices.com/jive?view=revision&revision=9507 == Bug: 15945 Description: force garbage collection when slideshow is running. Resizing larger images might cause memory issues.