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