cacheAsBitmap and Android: Graphical corruption and other issues

[xTLS]

We 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.

[leejk]

Hello,

I am having a similar issue when loading an external swf. Some of the loaded swf files display fine, while others display as seen in the attached screen shot, but only on the Nexus 10 device or emulator. I'm setting cacheAsBitmap to true on the loaded swf since it contains vector graphics. If I don't set the cacheAsBitmap property, then the problem goes away, but then the display performance is worse. Perhaps it is related to the higher resolution screen somehow on the Nexus? It seems like a bug to me tho. Has anyone found a fix or work around?

thx

[Eddy_Li]

Maybe you can try blitting your vector graphic into a bitmap for now. I had a problem that whenever I change the rotation of a vector graphic that is cacheAsBitmap, the text within the graphic will be messed up.

Blitting is extra work and, in my case, the quality suffers a lot when I rotate the bitmap, relative to rotating a vector graphic. I kept the vector graphic visible=false all the time, and kept it and everything within cacheAsBitmap=false. Just in case it does anything fancy.

You might run into a problem if you blit a scaled vector graphic though. Because bitmapData.draw() doesn't blit the scaled image by default, so the blitted result will be unscaled. I remember solving the problem by using a matrix when blitting, I think.

Anyways, at least that got the job done. It's almost like cacheAtBitmap manually, and painfully. Hope it helps. When in doubt, just blit the crap out of everything