One of the greatest new features of ActionScript 3.0 is without a doubt, the Display List. This is, after all, one of the reasons that the Flash 9 Player runs so ridiculously much faster than the previous versions. But what, you may ask, is it exactly?
The Display List
The Display List in a nutshell is AS3′s system for organizing all visual elements (MovieClips, text, JPGs, &c.) and displaying them on your screen. Adobe took the old paradigm of attaching MovieClips at certain depths within other MovieClips, chucked it all out, and built it over from the ground up. If Flash had started out using the Display List, you and I wouldn’t have had to spend nearly as much time learning all kinds of little tricks and work-arounds to all of the quirks inherent in the old Flash. In other words, this is how it should have been done all along.
The Players
The Display List is essentially a tree structure with the Stage at its base, DisplayObjectContainers as its branches and DisplayObjects as the leaves. Pretty! : -D
Stage
Ah, our old friend the Stage. This is pretty much like you would expect � the Stage sits at the root and contains everything that you see in your Flash movie. Everything that is contained by the Stage, or contained within something contained by the Stage, is considered part of the Display List and is rendered every frame.
You and Stage go way back, but did you know that Stage is now a DisplayObjectContainer as well? :-0
DisplayObjectContainer
A DisplayObjectContainer is a container that holds DisplayObjects. Duh!
In AS2, a MovieClip is the only element that can contain other visual elements and tasks like managing depth and attaching clips are wrought with issues. In AS3, DisplayObjectContainers (or rather its subclasses) handle this task only easier and more versatile. You can think of a DisplayObjectContainer having an array of visual elements because… it does. MovieClips are still around � they’re a type of DisplayObjectContainer that have their own timeline; however, you’ll probably be using a new element in AS3 called a Sprite (which is essentially a MovieClip without a timeline) for most purposes.
Containing DisplayObjects is great and all, but did you ever stop to think that a DisplayObjectContainer might also be a DisplayObject itself? :-!
DisplayObject
All visible elements, from text fields to bitmaps to shapes to movieclips and even the stage, are whimsical DisplayObjects (that is, they extend the DisplayObject class). All forms of DisplayObjects have the same basic traits like x, y, visible, &c. and each subclass has its own special supernatural abilities. DisplayObjects become visible by using the addChild() method of a DisplayObjectContainer in the Display List. Depth is handled as if it were controlled by unseen forces when you call addChild() or by reordering the array of children. You can even use removeChild() causing it to vanish from a container and then addChild() to make it reapparate in a different one!
DisplayObjects are truly majickal and should not be taken lightly by mere mortals! 8-?
Using the display list tree, Flash walks through every element in every DisplayObjectContainer within the stage and draws it. All of the children of all of the containers are accessible by using DisplayObjectContainer.getChildAt(). Yes, even those things that you throw on the stage like vector shapes and static text are totally accessible DisplayObjects in AS3!
Gone are the days when smart people like you are using up all your creative problem solving abilities on the basics (getNextHighestDepth() ahem!). Now you can start using your beautiful brains to come up with some really clever ways to manipulate onscreen objects.
The Composite Pattern
If this were a Victorian-era scientific publication, a la C. Darwin, I would call this post “On The Resplendency of the Composite Pattern and its Use in the Field of Visual Interfaces ~or~ Matters Pertaining to the Novel Use of the Display List for Great Effect”… but whatever, they just don’t make ‘em like they used to.
Composite is a simple yet powerful software design pattern that allows you to have different types of complex nested data share a common interface. In other words it allows you to program recursively without caring whether a thing is just a thing or a group of things. This is easier to explain by example…
Imagine a company called Bureaucracorp (Nasdaq:BURC). The Board requests a company wide report on productivity. The CEO placates them and calls all of the vice presidents into his office to report. The VPs go and ask all their department managers who ask all their lower tier managers who ask all the worker drones who ask all the outsourced Indian labour who ask all the… and so on down the line. The report comes back and the Board decides to close down their branch office in Slough, UK.
Why doesn’t the CEO have to ask each person at the company for a report? The CEO doesn’t care about the people under the VPs because the VPs represent entire groups of people (they are also workers themselves). Each group handles their own business (like hiring and firing) so the CEO doesn’t have to. This is the essence of the composite pattern and it looks like this:
Note: This diagram includes the names from the story above (ie. the Board)and also the traditional names of the elements of the composite pattern (ie. client)
Every underling is part of a group that can act as a whole and is represented by a manager. Does this sort of organization seem familiar? Think about how files and folders work. A folder may contain files or more folders (which are actually just a special type of file). You don’t need 2 separate commands to select a folder rather than a file. Most importantly, when you move a folder you can feel secure that the items within it are moving as well even though you may not even know what they are.
XML parsing in Flash works similarly but that’s another article.
The display list makes excellent use of this pattern to draw all of the elements. The Stage is like the CEO at the root of everything. Each DisplayObjectContainer (composite) in the Stage is responsible for drawing itself and all of its child DisplayObjects (leaves). If there were a function called draw() in the DisplayObjectContainer that draws the graphics on the screen, it might look something like this:
function draw():Void {
// draw this object
this.displayGraphicsOnScreen();
// draw all children objects
for (var i:uint = 0; i < this.numChildren; i++) {
var child:DisplayObject = this.getChildAt(i);
child.draw();
}
}
So after every frame you could imagine Flash calls the Stage.draw() method and the rest takes care of itself. This is a recursive method for traversing the children. I found an interesting article on methods for working with hierarchical data that go beyond the typical recursive method.
So where does this leave us? Hopefully all of this will give you a head start on working with the new Display List by understanding some of its inner workings. There's a lot more to it than what I mentioned here and I recommend checking out the documentation on display programming. I hope you also learned a bit about the Composite Pattern and how to recognize it. It's a very useful tool for working with hierarchical data structures. I think we're all going to be big fans of the Display List in the near future.