helping release loader under AIR (ImageItem.as)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. with an AIR app, load a bunch of jpegs, dump them and repeat.
2. with the profiler, see if the native Flash loader of ImageItem is
getting garbage collected.

What is the expected output? What do you see instead?
Ideally, see most or all of the loaders get garbage collected.  We do see
loitering loader objects

What version of the product are you using? On what operating system?
I believe the latest revision of bulk-loader we are using is r292.  

Please provide any additional information below.
- only loading items via ImageItem.
- I haven't specifically looked for loitering loaders in the profiler when
running our app in the browser, only AIR.
- I'm advocating adding "loader.unload()" in the destroy() method of
ImageItem.  I believe one will also have to check for null first, i.e. 
   if(loader)
     loader.unload()
But I guarantee you'll know better that I.  Also, I've made this change in
our local copy, so we are fine.  There is certainly no rush on this.  Just
wanted to give you a heads up and/or get it documented.

Many thanks and best regards,
Josh

Original issue reported on code.google.com by josh.fin...@gmail.com on 14 Aug 2009 at 4:13

[GoogleCodeExporter]

I am all for this and wanted to add that in CS4 (Flash Player 10 and AIR 1.5) 
the
loader.unloadAndStop() method is also available and should clean things out of 
the
loader more reliably then just doing loader.unload().

Original comment by ebr...@gmail.com on 3 Sep 2009 at 8:42

[GoogleCodeExporter]

Fixed as of revision 297.

If someone is able to verify an improvement on memory handling, I'd appreciate 
it.

Cheers

Original comment by debert on 7 Sep 2009 at 5:35

• Changed state: Fixed

[GoogleCodeExporter]

I can confirm that this does provide the desired improvement to memory handling 
in my
application. One thing I'd like to note, though, is that loader.unloadAndStop()
should probably be attempted before loader.unload(), as loader.unload() is 
available
in both FP9 and FP10, so in FP10 executing loader.unload() first may cause
loader.unloadAndStop() to not perform its 'stopping' functionality properly, as 
the
item would have already been unloaded. I haven't tested that behavior yet but it
seems like a safer ordering to me. Otherwise, looks good!

Original comment by ebr...@gmail.com on 8 Sep 2009 at 5:18

[GoogleCodeExporter]

Hi Ebrody.

Well put. I've commited rev 300 which will try unloadAndStop and if that is not 
available 
then "unload", which makes much more sense.

Thanks for the heads up.

Original comment by debert on 9 Sep 2009 at 1:55