15 Replies Latest reply on May 23, 2013 7:40 PM by nautilus1950

    Other Bitmap Memory

    scouterette Level 1

      While working on an app that includes multiple games, and testing memory cleanup between games, I came across a leak that i can't quite understand:  'Other Bitmap Memory' seems to be growing esponentially, never going down, and not folllowing any other memory stats. What is that indicating?

        • 1. Re: Other Bitmap Memory
          Michael J.A. Smith Adobe Employee

          Other Bitmap Memory includes memory used by rendering operations that aren't listed explicitly - for example, buffers and caches used for rendering text. Check that you don't accidentally leave anything on the display list between games, since this would still consume memory even if it isn't visible.


          The category also includes (somewhat confusingly) the memory for any sounds that you download using a URLRequest (if a sound is embedded in a swf, its memory will be part of the SWF Files category instead). Sorry that this is confusing - it's to do with the way Flash Player manages memory internally - we should separate out this sound memory into a separate category, to be clearer. Make sure that you release any sounds you're no longer using, after you're finished with them.


          btw, we'll be releasing Adobe Scout CC on June 17th, which includes a new memory allocation tracking feature, which would help you track down your leaks better! There's a video recording of the MAX session here:



          • 2. Re: Other Bitmap Memory
            Skrekkur3 Level 1

            Any ETA when or if Scout CC will be available under the prerelease program?


            And Can I see anywhere what Bitmap Filter buffers are excactly and if they can be cleared, as well as CacheAsBitmap buffers?

            • 3. Re: Other Bitmap Memory
              vikkiana Level 1

              Ah thanx! I narrowed down that leak and it was the call to System.privateMemory in my custom memory managing console that was swelling up the 'Other Bitmap Memory' index to 312 Mb in less than a minute.

              I had no idea that it was such an expensive call! And what gets stored in memory and never gets released in that call is a mystery.


              Anyway, i guess i don't need the console since i have Scout so I turned that off and the leak was gone.


              Thanx for the lead Michael, can't wait for Scout CC to come out

              • 4. Re: Other Bitmap Memory
                Michael J.A. Smith Adobe Employee

                I'm afraid there won't be a prerelease programme like before - but it's only a month to wait until the release of Scout CC. I'd love to give you it sooner, but we have to follow company schedules ;-)


                Bitmap Filter buffers are the buffers used by Flash Player to render display objects when you apply a filter to them. Remember that every time you apply a filter, Flash Player needs to render the object to a separate buffer, apply the filter in that buffer, and then copy the result back into the main buffer that you're rendering. You can't clear these buffers - they'll be disposed of automatically by Flash Player when they're not needed any more, but since the buffer is needed every time you render the scene, they won't get disposed of until you remove the display object that has a filter from the display list. If you're using too much memory in this category, try reducing the number of filters you're applying.


                CacheAsBitmap buffers, similarly, are used to store a cache of the result of rendering a display object for which you set the cacheAsBitmap property. It's a trade-off - caching the object will make rendering faster, assuming that it's a complex object to render and it doesn't change (NEVER set cacheAsBitmap on an animated object, as it'll recreate the cache every frame!). But the cache takes up extra memory, so you have to decide if the trade-off is worth it. If you want to understand this better, read the section on display list rendering in this article:




                @vikkiana: I'm surprised that System.privateMemory would cause Other Bitmap Memory to increase. Are you sure you weren't rendering the result to a text field, and hence continually allocating buffers for text rendering? If not, then I'd be really interested if you have some small example code that illustrates this (maybe we're not catching something in Flash Player) - you can email me at michsmit@adobe.com. In any case, I'm glad you fixed your leak :-)

                • 5. Re: Other Bitmap Memory
                  Skrekkur3 Level 1

                  Thank you for your clear answers. I am however a little confused about the Bitmap filter buffers, since this is in gpu-mode on an ipad, and only filters we are ... or should be using are for text, that we manually render to bitmaps. Since filters actually don't work otherwise. Guess I will need to investigate this further.


                  Too bad about Scout CC though. Am sort of on a deadline to finish retina version of our game this month, so CC comes slightly to late for that. Guess I have to use the old memory allocation profiler and scout to reduce the games memory footprint.


                  If you are interested in seeing what kind of game it is, you can go to www.playgodsrule.com or get it on the Canadian or new zealand app store. International release depending on the retina version

                  • 6. Re: Other Bitmap Memory
                    Michael J.A. Smith Adobe Employee

                    Sorry, I should have explained in a bit more detail. The Bitmap Filter Buffers are most commonly created because you apply a filter to a display object, but certain other operations, like scaling, result in Flash Player having to render to a separate buffer before compositing into the main image. These buffers also fall under the Bitmap Filter Buffers category. You're right that in your case it can't be an actual filter, if you're using the gpu render mode.


                    The best thing to do is to turn on DisplayList Rendering Details and take a look in the DisplayList Rendering panel. The memory in Bitmap Filter Buffers corresponds to the "Surfaces" that are shown in blue. You should be able to figure out which display objects are rendered to surfaces (a surface is just an off-screen intermediate buffer), and then look at what operations you're performing on them (like scaling) that could lead to this.

                    • 7. Re: Other Bitmap Memory
                      Skrekkur3 Level 1

                      I tried turning off filters that where being applied to text and both these buffers dissapeared.

                      So even if the actual object that has the filters is not on the display tree it still takes up space.


                      We maintain a reference to it because some text can be changed after it has been bitmapped, but perhaps we will have to remove all references to the textfield and recreate it if necessary.

                      It seems that some object/memory leaks were causing this buffer to skyrocket even more.


                      We are also considering removing all filters on text since it is quite the perfomance hog. All popups and stuff open a lot faster after we disabled them.

                      • 8. Re: Other Bitmap Memory
                        nautilus1950 Level 1

                        Hi Michael,


                        You mentioned "Are you sure you weren't rendering the result to a text field, and hence continually allocating buffers for text rendering?". I have a situation that's very similar to this where I have a String that gets assigned into a TextField on every frame with the code something like this


                        s = "";

                        function enterFrame($e:Event):void {

                             s += "extra text";

                             textField.htmlText = s;



                        running this causes "Other Bitmap Memory" to run up. Any advise on this?

                        • 9. Re: Other Bitmap Memory
                          vikkiana Level 1

                          BTW Michael, yes that was exactly the problem: leak was due to the repeated assigning of text strings to the main textfield for the console

                          • 10. Re: Other Bitmap Memory
                            Michael J.A. Smith Adobe Employee

                            If you're continually adding to a string on every frame, then the buffers required for text rendering are unbounded, as is the memory for the string. Since you presumably can't fit the whole string on the screen after a certain point, try rendering only the visible part of the string in the text field.

                            • 11. Re: Other Bitmap Memory
                              nautilus1950 Level 1

                              I have the code modified to this. extra text is pushed into a vector while the textField is always only displaying a portion of the strings.



                              var v:Vector.<String> = new Vector.<String>;

                              var top:int = 0;

                              const display:int = 45;

                              var i:int;

                              var last:int;



                              function enterFrame($e:Event):void {

                                   v.push("new text");


                                   top  = v.length - display;

                                   if (top < 0) top = 0;


                                   last = (top + display > v.length)? v.length: top + display;


                                   textField.htmlText = "";

                                   for (i = top; i < last; i ++) {

                                        textField.htmlText += v[i] + "<br />";





                              The code runs without "Other Bitmap Memory" issues when the bold section is commented out, but with it, consumption runs up pretty quickly.

                              I need the text in the textField to be updated, but still maintain the old text in memory so I can scroll back to them if i want to.


                              Message was edited by: nautilus1950

                              • 12. Re: Other Bitmap Memory
                                Michael J.A. Smith Adobe Employee

                                Think about what you're doing, for a moment - on every frame you're assigning a whole new fragment of HTML to a TextField. That one line of code where you set the htmlText property has a lot of stuff behind it - Flash Player has to go off and parse the HTML, figure out the layout, apply any styles, and then render the text to screen. That's expensive, and it's going to require a certain amount of memory for parsing and rendering buffers. And you're asking Flash Player to do this every frame. I don't know what your framerate is, but say it's 30fps - this is equivalent to expecting your browser to parse and render a new HTML document 30 times a second.


                                If you have a static document, it's a lot more efficient to set the whole document as the htmlText, and use the scrolling properties to only view a fraction of it. In your case, since your text is constantly changing, you should ask yourself the questions - (a) do you need the text field to update every frame? and (b) do you need to use HTML?


                                If you really want finer control of the memory usage, then you can use the Flash Text Engine - it's much lower level and you'll have to code a lot of the formatting functionality yourself, but the memory footprint is smaller. It's up to you to decide if the trade-off is worth it. See here:




                                Another point (though it probably won't make a difference) is that you're modifying the property as you construct the string. Since you don't know what work Flash Player is doing behind the scenes every time you set the htmlText property, it's safer to construct the string in a local variable, and then assign it at the end.

                                • 13. Re: Other Bitmap Memory
                                  nautilus1950 Level 1

                                  Well, it's not a static document. The "new text" in this case can be an arbitary line of text that's produced by the app/game which may or may not update on every frame (fastest being on every frame that is). What I'm trying to produce is something that resembles a computer console with text coloring, so htmlText is the easiest way to produce that.


                                  Performance aside, the memory that's being used for rendering html text isn't getting released. Running the text update 30 times a second vs once every second for 30 secs resulted in more or less the same issue. Tried using text engine without the html, and reusing existing TextLines, the same problem was there. :/


                                  Thanks for your input

                                  • 14. Re: Other Bitmap Memory
                                    Michael J.A. Smith Adobe Employee

                                    I took a look at the implementation, and whenever you set the htmlText property, the HTML you pass in gets parsed (the rendering is deferred, but the parsing isn't). This is a lot of work, so make sure you do as I suggested and construct the HTML string first, before assigning it to the TextField.


                                    The only other thing I can suggest, if memory is still a problem, is to try creating a new TextField when the text changes, and be sure to remove the old one from the display list and not keep any references to it. Any text rendering buffers should be attached to the TextField, and freed when it gets GCed. This might improve things (at the cost of the extra work in creating the new object and attaching it each time), or it could make matters worse depending on how often the GC kicks in. Could be worth experimenting with, though.

                                    • 15. Re: Other Bitmap Memory
                                      nautilus1950 Level 1

                                      var s:String;


                                      s = "";

                                      for (i = top; i < last; i ++) {

                                           s += v[i] + "<br />";


                                      textField.htmlText = s;


                                      updated the code to this, and also tried to recreate a new textfield instance with every update, then forced GC using GSkinner's localConnection hack. No difference in the issue. Memory doesn't seem to be reclaimed at all. Bummer.