Flash Player Mental Model - The Elastic Racetrack
DIGG IT!
11
Comments
Published
Tuesday, July 19, 2005
at
7:37 AM
.
Having worked with Flash since FutureSplash, I have come to some conclusions about how to think about the player during development. Welcome to the elastic racetrack.&
I think about the Flash Player as a racetrack. There are 2 distinct sections of the racetrack, one for executing ActionScript (subsection for event processing) and one for rendering content to screen. While running, the Flash Player loops around this racetrack at a preset speed designated as FPS in the SWF file. At all times the player will attempt to maintain the speed set regardless of what the player is asked to do. The designated FPS is the maximum speed of the racetrack and processing can never go faster than this limit but can go slower.
Player Racetrack
A SWF file tells the player to do certain things at certain times. As the player processes these instructions, the racetrack is stretched in either the ActionScript section or the Rendering section or both. If you are processing lots of data or rendering lots of clips, either half expands to process everything you add in a single loop of the track. The player will not skip over anything that it is asked to do and will always attempt to finish a loop in the least amount of time possible but never faster than the designated FPS.
ActionScript Heavy
Graphics Heavy
ActionScript and Graphics Heavy
There are several additional aspects that compound this model. First off, the player structures graphical elements into a descending tree. Starting at the base node(_leve0), there can be many branches each with frame content and sub nodes/timelines. With every loop of the player all of the elements on the tree must be processed. In the current F7 player, frame content is swept and processed in depth order as needed from the _level0 node. In terms of graphical performance, the key is to keep the tree shallow combined with making elements as simple as they need to be. The fewer items in the tree and the shallower the tree, the faster the graphics will render.
The tree structure also applies to ActionScript bytecode processing. In the AS phase, the tree is swept for bytecode given the tree's current state. Should any events be designated they will be processed in depth order. ActionScript is stack based and thus all bytecode is pushed onto the stack and processed in a linear fashion down the tree. Depending on the volume of code and events on a given frame, the AS portion of the racetrack elongates. As there is no build-in way to defer code execution, the player will process everything that it is asked to process in a given frame loop. It is interesting to note that even code that uses functions and events can be sequenced into a long line of bytecode to be processed. In a sense the player is never lossless, it will always do all the work you ask of it and never defer to a later frame cycle. The key is to never ask the player to do too much on a given frame and to be able to defer logic and events to later frames optionally.
As for Flash 8, from the looks of the beta player, cacheAsBitmap allows the graphics renderer to cache a MovieClip branch as a Bitmap. In caching vector graphics to an to a Bitmap, the renderer does not need to rerender until the graphics have changed (dirty). Ideally this allows the player to focus rendering on different areas of the player and specialize how the vector renderer is utilized. In a tree based rendering model, assuming some branches of the tree are set to branch.cacheAsBitmap=true, the renderer will create a Bitmap on the first pass and reuse this Bitmap until the vector graphicis of this area are marked as dirty. In the same light, if the cacheAsBitmap branch is dirty every frame(animated), you have forced the player to generate a Bitmap (processing + memory) with every frame cycle. In my testing, optimizing using cacheAsBitmap is not as straightforward as it seems.
In summary, the player performance is a combination of 2 distinctly different elements, graphics processing and ActionScript bytecode processing. If you abuse one or both of these aspects the player will slow down to make sure everything is completed before the next cycle. In development of larger projects, the elastic racetrack has helped me explain the logic behind many seemingly strange performance optimizations for Flex and Flash development.
As it has been said many times before, "Just wait a frame!" :)
Cheers,
ted ;)
Wow got to the inside
Good post, commenting this, I'll present this post on our FUG here in Brazil
Great Googly Moogly, that's a good post. In depth, simply explained, a wonderful analogy, and candy-coloured diagrams. I can learn anything with candy-coloured diagrams.
I'd love to see some performance numbers on the fp8 bitmap caching. Do we know what kinds of things will get an area of a vector graphic marked as 'dirty'?
Great post!
I always found useful to balance code processing and animation.
"Just wait a frame!" is my usual response to performance issues :)
What about timers for starting asynchronous operations?
Regards
Pablo,
The flash player handles networking in separate threads and calls events when data returns. These calls are made outgoing within the AS portion but return to the event area. This is true with all socket based communications XML, loadMovie, LoadVars, RSO, XMLSocket, and others.
These events are interesting as they queue up in the player waiting for an event window. When the player reaches this event block, events will execute to the point of the player not being able to return within the FPS time. In effect, network operations can be defered to the next frame.
Having tested XMLSocket allot and events from this class never seem to bog down the player. You can push allot of data through XMLSocket, I have tests that push 1000 round-trip messages through the server in about 1-2 seconds. The player doesn't blink at this.
Ted ;)
I believe that dirty is determined by changes to vector content or dependent child clips. Dirty is a determined down the tree as a change to a child node will force the dirty flag to be set up the entire tree to _level0.
Ted ;)
Very cool visual way of explaining it; thank you. :)
:P i posted my comment in the wrong post :)
here it goes again
Ted,
your article is quite nice. I translated it to spanish (thought it might be helpfull for latins to read what you posted, in their language), and I was wondering if there's a problem with you if I publish it in my blog, with credits to your original post of course.
What cause it to be dirty?
I guess alpha change does not dirty it, but like I've read on OSFlash, rotation and scaling probably dirty it? Why rotation?
Is it good only for move(x,y) change?
What if the clip is stopped? I would presume that no rendering takes place, but what about events? Does "event window" grow to consume 100% of the cycle?
Andris,
In players 2-7, every visual element is always rendered regardless if there is a stop command. Stop simply forces the renderer to cycle on the specific frame. Depending on the state of the DisplyList, everything in the tree will be rendered every cycle. The only exception is the cacheAsBitmap setting in Flash 8. The player will use the memory image for the render cycle and will not process child clips.
Events will always fire and will be allocated depending on the length of the event function called. You can have an 'onEnterFrame' function defines before or after a stop() method and it will execute. Events take as long as they take or until you hit the script timeout limit and a player dialog will occur.
Internally the player sweeps the DisplayList and processes all graphics, then processes all frame bytecode, then processed events. If there are things to do in each phase, the phase will expand potentially slowing down the frame speed.
Good question BTW!
Cheers,
Ted ;)
Ted,
It's a very good analogy. If you do not mind, I'll use it in the upcoming book (I'll mention your name, of course).
Thanks,
Yakov Fain