One of the easiest approaches to increase performance in Flash app is to remove any hidden objects from the Flash display list, and use the minimum amount of display objects. The code execution goes through the display list from the top layer, the Stage, and through the main Application class. Flash Player executes code and renders all the children in the display list from top to button until it reaches the display object. A container can be anything that extends the DisplayObjectContainer such as UIComponent, Group or a Sprite.
Especially with MXML, it’s very easy to nest display objects, however it’s VERY expensive every time we nest display objects, since each display object added to the display list is extending a class that extends a class etc. To understand why it is so expensive to nest. Let’s take a look at the display list class hierarchy.
ActionScript 3
When it comes to the Display list, up to ActionScript 3 all display objects used to be MovieClip. MovieClip class is the core class for animation in Flash Professional and early version of Flash (AS 1 & AS 2). Each movie clip symbol includes behaviors and functionality of display objects, as well as the additional properties for controlling the timeline. There are many cases where you don’t need that extra layer and overhead of the timeline and in fact AS3 introduced a new objects call DisplayObject. DisplayObject is the low level base class for all objects that can be placed on the display list it extends EventDispatcher (which is based on an object). It includes classes to help manage the object such as cacheAsBitmap and visual properties.
Display object containers are types of display objects that can also include child objects that are display objects. The DisplayObjectContainer includes methods to handle managing the children such as addChild, numChildren and removeChild.
There are times where you need to display graphics but don’t need a timeline. That’s when you rather use a Sprite, which extends DisplayObjectContainer. As general rule of thumb — you rather use DisplayObject classes or classes that are subclasses such as Bitmap, Shape or Sprite over a MovieClip.
Flex 3
Next is Flex being thrown into the mix. Flex core class for the display objects is the FlexSprite class, which is nothing more Then a Sprite with the ability to returns a string indicating the location of this object. Then comes UIComponent which extends FlexSprite and is the base class for every visual component in Flex 3. UIComponent includes keyboard and mouse interactions, but also allow disabling these interactions for objects that don’t need that — such as labels. It also includes many features such as accessibility, Styles, States, Invalidation & Validation, Databinding, Effects, Embedding fonts and much much more.
Flex 4
Next is Flex 4. Flex 4 is using a Group as the base container class for visual elements in Spark (just like UIComponent for MX). Then you have a list of component that can be used such as Skin, Graphic, HGroup and VGroup.
In addition to Group you have the SkinnableComponent, which is the super class for all Spark components, it defines the base class for skinnable components. The skins used by a SkinnableComponent class are typically children classes of the Skin class.
For instance, take the Spark Button component as an example. The ButtonBase class is the base class for the all Spark button components. The Button and ToggleButtonBase classes are subclasses of ButtonBase. Similarly, looking at other component such as CheckBox and RadioButton classes there are subclasses of ToggleButtonBase. The Button component then extends the ButtonBase class and uses the default skin, which includes a text label. You can then define a custom skin class to add an image to the control or anything else you need. The default button skin is spark.skins.spark.ButtonSkin, which extends Skin. What we end up in Spark are components that can be easily skin and changed, however they are heavier.
So let’s do some testing. In term of memory usage of display objects:
Shape: 224 bytes Sprite: 392 bytes MovieClip: 428 bytes UIComponent: 1036 bytes Group: 1200 bytes
Next, let’s test to see the Flash Player code execution time on a frame. I will be using the FrameStats tool I created few days ago. What I have done is created a quick test harness and added the method to the FrameStats tool. It allows you to see information in regards to the code execution time in Milliseconds for a frame or few frames. I will be dropping the framerate to 1 second (so it’s more clear to test and watch the results) and Then pass a method that will be added to display object and add display objects to the display list. Then we can track the frame life cycle in the console.
protected function creationCompleteHandler():void
{
frameStats = new FrameStats(FlexGlobals.topLevelApplication, false );
frameRateControl = new FrameRateControl( FlexGlobals.topLevelApplication, false, false, 1, 1);
var componenent:UIComponent = new UIComponent();
componenent.addChild( frameStats );
frameStatsHolder.addElement( componenent );
trace( "Sprite: " + getSize(new Group()) );
uicom.addChild( sprite );
frameStats.testingExecutionTimeOfMethod( methodToTest, 10000 );
}
private function methodToTest():void
{
sprite.addChild( new Group() );
}
]]>
</fx:Script>
<s:Group id="frameStatsHolder" />
<mx:UIComponent id="uicom" />
Display Objects
When adding 10,000 display objects I am getting the following for the main base classes constructor code execution and their childern:
Shape Constructor code of children executed: 276 Sprite Constructor code of children executed: 399 UIComponent Constructor code of children executed: 1078 Group Constructor code of children executed: 1195
As expected, the execution of the constructor code and each child constructor code takes longer when the class has many nested objects. It good to know that the Flash Player usually turn methods into native code except for the constructor, so the execution time takes longer on constructor than other classes and we should keep constructors with the least amount of code possible.
Adding 1,000 display objects
Button
Although, I added 10,000 display objects SimpleButton it took only 33 milliseconds on a 1 fps Player framerate the reason is that SimpleButton is low level and nest at the same tree level as DisplayObject. Spark Button takes much longer to go through the constructor code than Halo — however, interesting to see that Spark Button uses less execution time to render on the display list.
SimpleButton Constructor code of children executed: 33 Final user code executed: 730 Player renders changes display list: 304 mx.Button Constructor code of children executed: 820 Player renders changes display list: 7075 s:Button Constructor code of children executed: 2392 Player renders changes display list: 4539
Text
Adding text has interesting results as well. Spark Label did very well in term of rendering but still can’t beat Halo components in term of constructor time. TLF did very poorly on rendering (as expected) but decent on the constructor code.
TextField Constructor code of children executed: 68 Player renders changes display list: 168 mx:Text Constructor code of children executed: 743 Player renders changes display list: 685 S:Label Constructor code of children executed: 1136 Player renders changes display list: 198 s:RichText Constructor code of children executed: 416 Player renders changes display list: 3224
Conclusion
- Use low level classes such as TextField, SimpleButton (when possible) over halo and Spark. It will require more coding but will improve performance.
- Avoid using TLF
- Use Halo components over Spark components.
- When creating custom components use Sprite over MovieClip and UIComponent over Group
- When creating vector graphics it’s recommended to use Shape display object.




























