cacheAsBitmap and Android: Graphical corruption and other issues
xTLS Jul 12, 2013 5:25 PMWe have an AIR app released on iPad and Android. We started with iPad only but eventually the boss decided to move to Android and we overhauled the whole app to resize for different screen dimensions and released an Android version.
Many of our graphics in the Android version are vector shapes as this seemed to be the obvious solution with the flat-and-simple style of ICS. So we have cacheAsBitmap being set on all of the numerious shapes and TextFields. As time goes on and we add more features I am increasingly finding that cacheAsBitmap is causing serious rendering problems on the device that don't show up on the computer. Our Transformer Infinity in particular is having a lot of problems, possibly due to its higher resolution screen.
Early in development I was overzealous with cacheAsBitmap and would nest it: e.g. have a button with a vector background and text, do button.background.cacheAsBitmap = true, button.textField.cacheAsBitmap = true, button.cacheAsBitmap = true. If you do this nested caching too often or on a large parent it will cause all kinds of wackiness - components or text not rendering, or large rectangular holes in random graphics. Well, I figured that out and don't do that anymore.
But now we're encountering other issues. I had a dialog box that used cacheAsBitmapMatrix on the dialog, but not on any of its children. This rendered horribly incorrectly on the device - most of the components of the dialog didn't show up and those that did were cut off and misaligned. This might have been because one of its children was a bitmap from the library - I ended up fixing the issue by caching all of the vector children individually instead of the dialog on whole.
Then we noticed that a decoration with a scrolling background and a mask was cutting holes in cacheAsBitmap vector shapes as the masked part of the background moved over them. Now I'm having an issue where a vector button only renders correctly once and the next time it is supposed to be drawn only a tiny sliver of it appears. This problem happens in a release APK, but not while using Debug on Device via USB, which doesn't make any sense to me.
The problems seem to be increasingly rapidly as we add more shapes to the app. Is there a limit to how many shapes AIR can reliably cacheAsBitmap on a device? If anyone has any tips for alleviating this issue easily, that would be great, but otherwise it looks like we might have to use PNGs instead of shapes, which will make the APK larger, or BitmapData.draw, which increases load times and requires a bunch of extra code. If anyone knows a good article about these quirks they can point me too, I'd appreciate it.


