Chapter 6: Display List

Section 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 flexible--entire 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.

This excerpt is from ActionScript 3.0 Cookbook. Well before Ajax and Windows Presentation Foundation, Macromedia Flash provided the first method for building "rich" web pages. Now, Adobe is making Flash a full-fledged development environment, and learning ActionScript 3.0 is key. That's a challenge for even the most experienced Flash developer. This Cookbook offers more than 300 solutions to solve a wide range of coding dilemmas, so you can learn to work with the new version right away.

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.

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.

Section 6.1: Adding an Item to the Display List

Problem

You want to add a new display object to the display list so it appears on-screen.

Solution

Use the addChild( ) and addChildAt( ) methods from the DisplayObectContainer class.

Discussion

The Flash Player is composed of two main pieces that function together to form a cohesive unit, the ActionScript Virtual Machine (AVM) and the Rendering Engine. The AVM is responsible for executing ActionScript code, and the Rendering Engine is what draws objects on-screen. Because the Flash Player is composed of these two main pieces, drawing an object on the screen is a two-step process:

1. The display object needs to be created in the ActionScript engine.
2. The display object is then created in the rendering engine and drawn on-screen.