views:

947

answers:

3

Loading images into Flex (size < 100kb) causes IE7 memory increase by a megabyte per image. What's going on here? Here is the code I have -- this for each image:

var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_Error, Retry);//retry it
loader.contentLoaderInfo.addEventListener(Event.COMPLETE,
  function(event:Event):void
  {
    var bitmap:Bitmap = (e.target.loader as Loader).content as Bitmap;
    // save it & Load next
  });
loader.load(new URLRequst( imageURL ));

This also happens in Chrome (2.0.172.33) & Firefox (3.0.10). How can reduce the memory usage? Thanks!

A: 

Try tracing through your function in the Event.COMPLETE event listener to make sure its hitting it exactly when you expect it to.

Might be better to just store the imageURL in an ArrayCollection then reference that by binding to an image itself... for example

<mx:Image source="{myAC.getItemAt(6).imagePath}" ...

or   var tmpImage:Image = new Image();
     tmpImage.source = myAC.getItemAt(i).imagePath;
Chris Klepeis
sri
I guess I'm just not sure why you're using a loader and URLRequest when you can just set the source of an image... even if you're looping through each image and creating a new Image object.
Chris Klepeis
+1  A: 

Are there any browsers or browser/OS combinations where you don't experience this issue?

I've worked through a couple of difficult memory issues and I've found that the Profiler is more than worth the extra $500 for the Flex Pro license, if that is an option for you.

I don't know why you're seeing a 1M jump each time you load an image, but I do know that the browser requests chunks of memory from the OS when it sees that it needs additional memory - sort of like buying in bulk. So, it makes some sense that the memory increase would be greater than necessary.

I may be (am probably) way off on this, but the anonymous function being used to handle the complete event feels like it could be causing a memory leak for you. My thought is that the contentLoader can not be removed and contains a copy of the image's bytearray. This is not a researched theory - if I have time later today, or tomorrow, I'll see if I can do some and back this up (or correct myself).

Ross Henderson
+5  A: 

I don't think that an increase of about 1 Mb per image is something to worry about necessarily. You point out that the images are less than 100 Kb, but you're probably looking at the wrong number: for example, a 640x480 jpg that I've just been sent takes ~48 Kb, but if you do the math, the raw image takes up 900 Kb (640 * 480 * 3 = 921,600). And if you use transparency, multiply by 4 instead of 3. The thing is that the player has to unpack the image in order to manipulate it. Storing the raw bytes alone for such an image can take up 1 meg or more (depending on its size).

Rather than focusing in reducing the memory usage per image (which is a rough estimate anyway), you're probably better off checking that you're cleaning up after yourself when you're done with the images. Failing to do that could lead to more serious problems. I agree with rhtx that Flex Builder's Profiler is a good tool for detecting leaks, if that's available to you. A simple test, in this case, could be loading an image, taking a memory snapshot, unloading the image, forcing a GC, taking a second snapshot and comparing it to the first one.

Juan Pablo Califano
+1 for pointing out that loaded images, no matter how well compressed, end up as bitmaps. A surprising number of folks don't realize that's what happens.
Christian Nunciato
Thanks. This is what I've been missing. They are JPEG images on the server.
sri