Multimedia applications often have interactive elements based on video: For example, a pre-rendered 3D scene that moves according to a user’s interaction. The trick, in such a scene, is to play specific parts of the movie forward and backward to fake movement.

This sculpture has been rendered as a movie, with the camera panning 360˚around the object.
(Drag with the mouse to turn the object)

Embedding Animations

There are three basic ways to embed an animated scene into Flash:

• In the Flash Video format (FLV);
• As a sequence of images, e.g. PNG or JPEG;
• As a sequence of vector graphics.

The latter is often forgotten. Tools such as Cinema 4D’s FlashEx renderer can export a scene as a vector animation. If the scene doesn’t contain many objects and has simple texturing, a vector animation would probably be the way to go. The file size stays relatively small, plus the graphics are scalable.

A simple 3D object rendered as a vector sequence with FlashEx 2.
(Drag with the mouse to turn the object)

The other two methods, FLV and image sequences, are both pixel based, but have their own pros and cons. FLV has a decent quality/size ratio. Flash CS4 does not allow F4V files to be embedded directly, so the best codec is the older and less compressing On2 VP6. Interacting with FLV, e.g. jumping between frames quickly or playing it backward, is heavy on the processor. Presumably, the Flash Player has to jump to the nearest proceeding keyframe and process the changes to the current frame each time. On the other end of the spectrum is the image sequence. The compression is on a per-frame basis, so the overall file size will usually turn out much bigger. The display performance, however, is far better than FLV.

Eliminating the Cons

A combination of the reduced file size of FLV and the performance of an image sequence is possible, if the data gets decompressed on the client side. H.264 encoded video data could be sent through the wire and then be processed into an uncompressed image sequence before being displayed. I wrote a class named BitmapAnimation that parses each frame of a MovieClip (including any FLVs within) and adds it to an array of bitmap data. BitmapAnimation has the same methods as a MovieClip (gotoAndPlay, currentframe etc.), so the two can be interchanged. For instance, I was able to use a BitmapAnimation in place of a MovieClip to create a MovieMaterial in Papervision3d – polymorphism works.

When compared with simultaneously running FLVs, BitmapAnimations showed a 500% performance increase on my system. The difference was even bigger with the clips running backward. There may be a performance benefit in converting complicated vector animations to a BitmapAnimation before they are displayed. I have, however, not recently come across a scenario where a pure vector animation alone caused the frame rate to stagnate.

The MovieClip option cacheAsBitmap requires, to my understanding, the frame to be rendered in the Flash display list before it takes effect. This would be the only major difference to BitmapAnimation (where the image is rendered before being displayed). Enabling cacheAsBitmap on MovieClips containing FLV did not show a change in performance in my tests. Because a video is usually viewed once, it makes sense not to cache FLV by default.

There is one known drawback when using a BitmapAnimation: Depending on the size of the video and the client’s processor speed, the Flash Player could “freeze” for a few seconds while decompressing the video data. I created an additional class, where I lengthened the processing time by decompressing one frame per half-second. This would allow the video to be prepared in the background without noticeably slowing down the rest of the application. Delayed processing would work best during a loading sequence, where the video is loaded first, then converted to a BitmapAnimation, while the rest of the assets are being retrieved.

Usage

Simply pass a MovieClip to the draw method.

bitmapAnimation = new BitmapAnimation();
bitmapAnimation.draw(movieClip);
addChild(bitmapAnimation);

The imported bitmap data can be reused with multiple BitmapAnimations.

var bitmapAnimation1:BitmapAnimation = new BitmapAnimation();
bitmapAnimation1.draw(movieClip);
var bitmapAnimation2:BitmapAnimation = new BitmapAnimation(bitmapAnimation1.bitmapSequence);

Conclusions

Pre-rendering a complex MovieClip, such as embedded FLV, using the BitmapAnimation class, may likely show a performance increase. Also, this method may remove the need to embed an image sequence where display performance is an issue. Due to the computation time required for conversion, BitmapAnimations should not be used for long clips. Inputs and feature requests are welcome, just add a comment below.

Download the classes BitmapAnimation and DelayedBitmapAnimation.

Download the blimp example.

Screenshot from the 1995 racing game Destruction Derby

It seems that the graphics performance is comparable to games that came out in 1995 on the PC, before graphics hardware became widespread. Imagine running a game like Dark Forces or Destruction Derby inside the browser. In a nutshell, on today’s average computer, the Flash graphics performance is Quake 1 tops. Broad statements aside, it is important to know what code flies on the Flash Player when developing games and interactive applications.

I’d like to know what basic code will perform best in a given situation. Therefore, I have started to extract these parts of code from my projects and test them against alternative methods, attempting to quantify the execution speed on the AVM. Unlike Javascript, ActionScript usually runs on the same engine; This makes such specific tests worthwhile.

I have gathered performance tests from a couple of my projects and put them into the ActionScript Performance Wiki. It is open to anonymous editors, so anybody is free to add their own tests.