Vivisecting Media

Flash Internals: Byte Code, Control Tags, Renderers… oh my! (part two)

During the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

Read Part One: Motto’s and Percentages.

Byte’ing the Hand That Feeds

When an application is compiled from a FLA or mxmlc the generated SWF file has two main components that control how the application behaves: Byte Code and Control Tags. The Byte Code is the generated ActionScript. Control Tags are currently only produced from Flash Authoring.

The generated Byte Codes are loaded into the Player via the SWF and are sent to the Flash Player ActionScript Virtual Machine (AVM) for processing. The AVM processes the Byte Codes and then manipulates the current Display List based on the commands within the code. The Display List is a tree based structure that represents an asset hierarchy within the SWF. These assets are MovieClips (Sprites / Components), Audio elements, Video elements, etc. The assets are added, updated and removed from display list by the AVM. In the following example, the code is compiled down into a Byte Code set that at run time informs the AVM to create a new Button and then add it to the display list.

var myButton:Button = new Button();
Application.application.addChild(myButton);

Control Tags skip the Byte Code and AVM step and directly access the Display List. Control Tags were briefly mentioned but from what I recall when I worked at Macromedia/Adobe, the timeline’s keyframes are compiled into Control Tags and when processed by the Player they update the stack according to how the keyframe interaction was defined.

Render Me This

There are two types of renderer’s in the Flash Player, immediate and retained. The vector engine that Flash is famous for is a retained renderer. The example that was used was that we request two boxes to be drawn in the same render pass (or frame): a red rectangle and a black rectangle. The black rectangle is 40px by 40px, is located at 10,10 on the stage and is requested first. The red rectangle is 200px by 200px, is located at 0,0 and is drawn second.

The retained renderer is a smart rendering system and sees that the black rectangle is covered by the red rectangle and therefore the rendering system skips drawing the black rectangle. This process helps memory usage and other system gains but it is a more time consuming process because all the drawing requests have to be made before the render pass is completed.

As I mentioned earlier, there are two renderer’s in the player. The second renderer is the Bitmap renderer which is an immediate render and happens off stage. This means that as data is requested to be drawn in the Bitmap renderer buffer, the update is done at the time of the request. This makes Bitmap rendering much, much faster and is one reason why changing animations and other assets to bitmaps can offer an increased performance gain. For more information about Bitmap Caching performance check out Guy Watson’s “Using Bitmap Caching in Flash”.

I was going to delve into the AVM deeper in this post, but looking at what I have to talk about I am going to save that for part three!

Update: Read Part Three: The ActionScript Virtual Machine
Read Part Four: Just-in-time (JIT) compilation