Bitmap DisplayObjects cause a memory peak that kills IOS devices

[DavidJoju]

Hey there

We are creating a game using Starling in Adobe Air for IOS, Android, Kindle and Facebook and are coming across an issue with Bitmap DisplayObjects. The following profiling session was recorded in an android device with 1GB of memory:

http://dev.jojugames.com/projects/wicked/AndroidLogTutorial/001_CPUPeak.png

The problem is that IOS devices have only 512MB and crash frequently at the peak shown in the image above (154MB CPU + 148MB GPU, 302MB Total)

This peak happens because for 400 frames or so the AIR runtime decides to create some objects called "Bitmap Displayobjects" as a cache for decoded compressed textures to avoid re-decoding them in the future, and keeps these objects in memory for some arbitrary time (we tested disposing every single bitmap and texture but these objects remained in memory). The next figure shows these bitmap DisplayObjects in time:

http://dev.jojugames.com/projects/wicked/AndroidLogTutorial/002_BMDisplayObjects.png

The creation of these objects seems to be arbitrary because there are many times in the game where textures and bitmaps disposed and recreated because the game state changes (from map to game and vice versa), these parts are shown in the scout screenshot above with gray arrowed boxes.

We need to avoid creating these Bitmap DisplayObjects altogether, we don't care if texture decoding takes a little longer.

Please notice the following:

* From the first screenshot: the game uses half the memory of the peak during all gameplay

* From the second screenshot: most of the memory in the peak are these Bitmap Displayobjects.

* From the second screenshot: A lot of textures are created and uploaded to GPU memory without the use of Bitmap DisplayObjects.

Can anybody help us to configure the AIR runtime to avoid using these Bitmap DisplayObjects?

Thanks!

[DavidJoju]

I forgot to mention that we are using Adobe Air version 13.00111.

[User_Unknow]

Try to init your Starling on iOS with disabled Context Lose option. So Starling will not store all data in the ram. iOS dont't loose context comparing to Android

[jadams602]

It is not true that you can't lose context on iOS. If you are using the latest versions of Starling you don't have to store Bitmaps in memory either to restore context.  Storing Bitmaps in memory is the old way to handle restoring context in Starling.

[DavidJoju]

Right now we are disabling context restore in all platforms (Starling.handleLostContext = false) because we have our own context restore mechanism so that's not the problem. Given that the Starling restore context cached textures are not the issue, does anybody know how to prevent these Bitmap DisplayObjects from ever been created?

ps: our context recovery mechanism does't create any extra bitmaps or textures of any kind.

[jadams602]

Assuming these aren't flat out memory leaks (ie they will eventually garbage collect but you don't like their current buildup) you might be able to use appropriate timely calls to System.pauseForGCIfCollectionImminent to keep the buildup flat and stable...

[DavidJoju]

Thanks for the answer.

The problem we are facing is between frames 140 and 500 of the game's execution (the first 4 minutes of gameplay), after that the game runs flat because we dispose the assets periodically and call System.gc. We saw in scout that the memory is indeed flat after these 500 frames (not because lack of proper disposal but because the Bitmap DisplayObjects are not created so aggressively anymore).

Our problem is these Bitmap DisplayObjects at the beginning, you can see them in green in this image:

http://dev.jojugames.com/projects/wicked/AndroidLogTutorial/002_BMDisplayObjects.png

We made an experiment in which we load, instantiate and upload to GPU memory one of the textures that's provoking instantiation of Bitmap DisplayObjects and disposed both the bitmap and the texture right away, also we called System.gc. We noticed in scout that the bitmap was removed from CPU memory and the texture was removed from the GPU memory but the Bitmap DisplayObjects remained in main memory for about 300 frames.

It's worth mentioning that after the initial 500 frames the Bitmap DisplayObjects are not created as aggressively as they are created at the beginning of the execution, that can also be seen in the screenshot on this post.

That said, does anybody knows how tho prevent these Bitmap DisplayObjects from ever being created at the beginning of the game's execution?