Bugzilla – Bug 12763
Artwork resizing uses too much memory
Last modified: 2010-04-08 17:24:16 UTC
Resizing a lot of images in the scanner uses too much memory and gets the process killed. We need to either spawn a new process to do each image, or possibly use command-line resizing tools. Should also try to make it faster (lower quality) while we're at it.
Why is it using so much memory, is there a leak?
It's libgd, it's pretty bad especially when resizing a very large file. But I have a plan, running resize operations in a separate process (fork/exec or Win32::Process or whatever). This means all slow resize operations can also be async.
Got it. Would small images still be done in process? (I'd worry that the fork could be the expensive part of that operation...) On Jul 16, 2009, at 6:03 AM, bugs@bugs.slimdevices.com wrote: > https://bugs-archive.lyrion.org/show_bug.cgi?id=12763 > > > > > > --- Comment #2 from Andy Grundman <andy@slimdevices.com> 2009-07-16 > 06:03:05 --- > It's libgd, it's pretty bad especially when resizing a very large > file. But I > have a plan, running resize operations in a separate process (fork/ > exec or > Win32::Process or whatever). This means all slow resize operations > can also be > async. > > -- > Configure bugmail: https://bugs-archive.lyrion.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
GD is so slow that it's probably best to just do it for all images. Will have to benchmark it.
Reset priority before triage.
since GD no longer appears to be getting developed, and is the cause behind at least one SBS crashing bug 4699, and since GD is so slow, perhaps imagemagick should take over if its faster? iow's why continue to keep trying to use GD, if imagemagick is better? also, could GD become a security issue if its no longer being patched against exploits?
I do want to look at using ImageMagick as it may be faster, but we use GD for a lot of things and it would be a significant effort. For example, GD is also used for rendering true-type fonts on the ip3k display.
== Auto-comment from SVN commit #29140 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29140 == Bug 12763, Add support for resizing image files and audio tags directly within ImageResizer. Using files instead of refs saves a lot of memory.
== Auto-comment from SVN commit #29144 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29144 == Bug 12763, updated standalone gdresize script
== Auto-comment from SVN commit #29146 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29146 == Bug 12763, use gdresize script during scanner precache phase
Reduce hours.
== Auto-comment from SVN commit #29163 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29163 == Bug 12763, rewrote artwork code to be asynchronous and ususe a queue of gdresize processes to resize artwork, saving memory and improving performance. Still a bit more work to do, and this probably needs tweaked for Windows support
This seems to be pretty good now, marking fixed.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!