You may have heard that the cacheAsBitmap functionality introduced in FlashPlayer 8 and available since Flex SDK 3 can sometimes help you improve performance. That is true, but only as long as the disply object is only moved.

• If you apply any other transformation on the display object, FlashPlayer will cache a new rasterised version of the object for each iteration of the transformation.
• If you apply any filters to your object, two versions are cached, one “normal” and one for the filtered result.

Both of these things may result in a higher than necessary load on your CPU and memory resources, when doing anything but only moving the display object.

Therefore, use cacheAsBitmap only on display objects that you know will only be moved around the stage, never on objects that will have any other sort of transformation.

An added problem with cacheAsBitmap is a known “bug” in the Mac version of the FlashPlayer where display objects that are using it can misunderstand their own redraw regions, resulting in a corrupted view. It seems rather rare though.

Also, when extending UIComponents – the default FlashPlayer behaviour is to heuristically try to find out if you usually cacheAsBitmap. If you look at the code in UIComponent of Flex 3 SDK you will find the following statement:

private var _cachePolicy:String = UIComponentCachePolicy.AUTO;

To make sure that the default behaviour of all of your objects that inherit from UIComponent instead inherit from your own extension of UIComponent which could invoke

this.setCachePolity = UIComponentCachePolicy.OFF

There are many people out there who have opinions about the cacheAsBitmap functionality as it is implemented today. Two examples are:

• Why cacheAsBitmap is bad
• Vote for a new cacheAsBitmap behavior!
• Flex Move Effect Messes Up Mask Alignment