Previous Page
Next Page

6.0. Introduction

The rendering model for ActionScript 3.0 and Flash Player 9 is radically different than in previous versions. Traditionally, the MovieClip was the focal point of the renderer. Every .swf movie contained a root MovieClip (commonly referred to as the Stage). The root MovieClip could contain child MovieClips, which could, in turn, contain more child MovieClips. The concept of depths was used to control the stacking order in which MovieClips were drawn (objects on higher depths appear "on top"). Methods such as createEmptyMovieClip( ), attachMovie( ), or duplicateMovie- Clip( ) were used to create MovieClips. Anytime a MovieClip was created, it was automatically added into the visual hierarchy and consequently drawn by the renderer. MovieClips weren't able to move to different places within the hierarchy; instead, they first had to be destroyed and then recreated before they could be positioned elsewhere in the display.

The new renderer is still hierarchical, but not as rigid, and aims to simplify and optimize the rendering process. The new rendering model centers on the display list concept and focuses on the classes available in the flash.display package. The display list is a hierarchy that contains all visible objects in the .swf movie. Any object not on the display list is not drawn by the renderer. Each .swf movie contains exactly one display list, which is comprised of three types of elements:



The stage

The stage is the root of the display list hierarchy. Every movie has a single stage object that contains the entire object hierarchy of everything displaying on the screen. The stage is a container that typically contains only a single child, the main application class of the .swf movie. You can access the stage by referring to the stage property on any display object in the display list.



Display object containers

A display object container is an object that is capable of containing child display objects. The stage is a display object container. Other display object containers include Sprite, MovieClip, and Shape. When a display object container is removed from the display list, all its children are removed as well.



Display objects

A display object is a visual element. Some classes function as both display objects and display object containers, such as MovieClip, while other classes are only display objects, such a TextField. After a display object is created, it won't appear on-screen until it is added into a display object container.

The hierarchy tree for a display list might look like something in Figure 6-1. The stage is at the very top of the hierarchy, with display object containers as branches and display objects as leaves. The items at the top of the diagram are visually underneath the items at the bottom.

Figure 6-1. An example display list hierarchy

Transitioning to the display list realizes a number of benefits for programmers over working with previous versions of the Flash Player; these include:



Increased performance

The display list contains multiple visual classes besides just MovieClip. Classes such as Sprite can be used to reduce the memory requirements when a timeline isn't necessary. Additionally, a Shape can be used to draw into rather than relying on a full MovieClip instance. By having these lighter-weight classes and using them when possible, precious memory and processor resources can be saved, resulting in improved overall performance.



Easier depth management

The hierarchy of the display functions as depth management under the new display list model. In the previous model, methods such as getNextHighestDepth( ) were used to create MovieClips on the correct depth, and swapDepths( ) was used to control the visual stacking order. Depth management was cumbersome and tedious before and often required extremely careful programming. It was a fact of life that just had to be dealt with because it was so intertwined with the language. The new display list model handles depth almost automatically now, making depth management almost a thing of the past.



Less rigid structure

The previous model featured a fairly inflexible and rigid hierarchy. To change the hierarchy, MovieClips had to be destroyed and recreated at a new location. This was a time-consuming and expensive operation, and often was painfully slow. The new display list model is much more flexibleentire portions of the hierarchy tree can be moved via the new reparenting functionality (discussed in Recipe 6.1), without suffering the performance penalties of creating and destroying elements as before.



Easier creation of visual items

The display list rendering model makes creating display objects easier, especially when creating instances of custom visual classes. The previous model required extending MovieClip, combined with using special linkage that associated a library item with the ActionScript class. Then attachMovie( ) had to be used to actually create an instance of the custom class. Under the display list model, you extend one of the many display object classes, but you use the new keyword to create instances of custom visual classes, which is much more intuitive, easier, and cleaner. See Recipe 6.4 for details.

As noted earlier, the flash.display package contains the core classes for the display list model. The old model focused on the MovieClip class, but the display list revolves around the DisplayObject class and its various subclasses. Figure 6-2 illustrates the display list class hierarchy.

Figure 6-2. The display list class hierarchy

Each one of the core classes is designed to serve a specific purpose. By having more than just MovieClip available, the display list offers more flexibility to programmers than the previous model. The more commonly used display classes are listed in Table 6-1.

Table 6-1. Commonly used display classes
Display class Description
                           DisplayObject

The base class of all display list classes. DisplayObject defines properties and methods common to all display classes. The DisplayObject class is not meant to be instantiated directly.
                           Bitmap

The Bitmap class allows for the creation and manipulation of images via the BitmapData methods; it is described in Chapter 8.
                           Shape

The Shape class contains a graphics property that allows for drawing using lines, fills, circles, rectangles, etc. Chapter 7 has more information.
                           Sprite

Sprites are similar to shapes, but can contain child display objects such as text and video. A Sprite can be thought of as a MovieClip without a timeline.
                           MovieClip

MovieClip is the familiar class with a timeline and methods for controlling the playhead. Because MovieClip is a subclass of Sprite, you can draw inside of it, and it can contain child display objects as well.
                           Video

The Video class lives in the flash.media package, but is also a subclass of DisplayObject. Video instances are used to play video, as described in Chapter 16.
                           TextField

The TextField class, found in the flash.text package, allows the creation of dynamic and input text fields. See Chapter 9 for more information.
                           Loader

Loader instances are used to load in external visual assets, such as other .swf movies or image files.

If you've worked with Flash in the past, transitioning to the display list model is going to take some time. Old habits are hard to break, and display list programming has a lot of depth. However, once you get into the swing of things you'll see that the time it takes to learn the new model is well worth it. The display list dramatically changes Flash display programming for the better.


Previous Page
Next Page
Converted from CHM to HTML with chm2web Pro 2.85 (unicode)