1 Reply Latest reply on Jun 20, 2013 12:57 PM by Michael J.A. Smith

    Garbage Collection doesn't align with disposal of Bitmap DisplayObjects

    Zen Seven



      So I've been diving into using Adobe Scout CC, and it's great. However the telemetry that I'm receiving on my Starling based app is confusing me. I have 2 scenes, in which I transition between them by fading the alpha channel. Afterwards I expect the garbage collector to kick in and delete all my objects. However, when the GC kicks in, nothing happens. It isnt until many frames later of inactivity that the bitmap DisplayObjects dissappear all by themselves, for no rhyme or reason. I've attached a link of the screenshot of Scout for your viewing.




      I'm curious - what's going on here? Is this is a bug / bad data issue with Scout, or am I not understanding how the garbage collector works? Perhaps a clarification of what is contained within the "Bitmap DisplayObjects" category would help too.


      I really wish we chould just kick the GC - especially on limited memory devices like the iPad 1. The GC seems to be just too slow.



        • 1. Re: Garbage Collection doesn't align with disposal of Bitmap DisplayObjects
          Michael J.A. Smith Adobe Employee

          Bitmap DisplayObjects refers to the memory used to store the decompressed version of any images you load. (you can read a detailed description of what all the categories mean, here: http://www.adobe.com/devnet/scout/articles/scout-memory-profiling.html)


          This memory gets created the first time you use an image (unless you specify ImageDecodingPolicy.ON_LOAD). The memory is linked to the image, so as long as the image is still referenced, the decompressed version is still sitting in memory. Running the garbage collector won't do anything, since the image is still referenced. However, Flash Player has an optimisation that if you don't use an image in a certain time (you still have a reference to it, but you're not actually accessing the decompressed BitmapData), then it'll free the decompressed version of the image. If you use it again, it decodes it on demand again, from the raw compressed data. This is a trade-off between time and memory - if it released the decompressed image after every use, it would be spending too much time repeatedly decompressing the same image. Which is why it keeps the decompressed version around for a while, since you might use it again. Unfortunately, you don't have control over this mechanism.


          Hope this helps,