This site is now just an archive over the rise and fall of Flash. The domain flashmagazine.com is available for sale
Login | Register

Flash Performance

In this paper so far we've covered many disadvantages of the Flash platform, nearly all of which are fairly minor and can be worked around. Flash is like any platform, with its own list of weird quirks and annoying features and bugs. However, there is one major problem that deserves its own section: performance.

By Scott Bilas, Oberon Media, Inc. ActionScript can be very slow. Bytecode execution is ok, probably on par with other scripting languages, but there is a significant problem with entry points. Setting up the execution context to call into the virtual machine and tearing it down again after a function exits is extremely expensive. Less expensive, but still significant, is a script-to-script function call.

Optimizing ActionScript is straightforward:

- Minimize entry points into the code. For example, use a traditional game main loop rather than a lot of onEnterFrames attached to MovieClip-derived classes for every game object on the screen.

- Profile, profile, profile. Nothing shows what's slow like ASProf (see Flash Resources at the end of this paper).

- Manually inline functions when necessary. When in inner loops, use local variables, which are specifically optimized in "registers", instead of global variables.

- Publish for Flash 7, which is much faster than Flash 6 (mostly due to the "registers").

- Scan the blogs and mailing list archives for tips on optimizing ActionScript performance. There are many tricks out there, too many to cover here, but this site gathers a lot of analysis and links in one place:
http://www.oddhammer.com/actionscriptperformance/old_index.htm

Note that many of these may be out of date due to Flash 7 and need re-testing.

Worse than scripting performance is graphics performance. Flash is basically a 2D rasterizer in software with zero caching other than on the primary surface. Each bitmap being rendered is actually a textured fill of a four-sided shape, rendered through a generic rasterizer. It's very pretty, but can be very slow. Little work is apparently done inside the Player to optimize for bitmaps on integral coordinates with an identity texture transform. There is a dirty rectangle system that works fairly well, but it is spoiled by a final step in the renderer that unions all the dirty rectangles together for the final update area. This means that on a screen with a lot of detail, a flashing icon in one corner of the screen, with the gameplay action in the other corner, causes the entire screen to be redrawn each time the icon changes. There is also overhead in maintaining each graphical object on the screen, and managing it as part of the display list.

Optimizing graphics is also straightforward, although it may not be very appealing:

- Avoid making action games where the whole screen is scrolling. Feeding Frenzy is a great example of something not to attempt in Flash.

- Minimize the number of objects onscreen at once.

- Avoid UI designs that have animated indicators at the edge of the screen. These will expand the final union size for dirty rectangle rendering, increasing the update cost.

- Avoid large full-screen effects unless the screen is very simple (such as on a rewards screen). If possible, downshift the quality temporarily while a large full-screen effect is playing.

- Target frame rates for 16 or 20 fps. A consistent frame rate feels much better than a high frame rate, and it reduces the per-frame overhead that Flash incurs from maintaining its objects.

- Use lower resolutions - the graphics problem only really kicks in at higher resolutions. For web resolutions, we can get away with pretty much anything. At 800x600 though, the pixel throughput of Flash really starts to hurt.

- If an animated object needs to be hidden, remove it from the screen instead of setting its _visible member to false. An invisible animating object still (inexplicably) dirties the screen.

There's really no way around it. Flash is not designed for fast paced full-screen animated graphics of any complexity, but with careful optimization and some modifications to the game design we can still make it work for us.
Odds and Ends >>>

 

Next tutorial:
Odds and Ends

Previous tutorial:
Advantages of Flash

Get new stories first

Click to follow us on Twitter!

 

Comments


Posted by rebelheart on 08/07 at 04:46 PM

This whole series of ‘papers’ is informative and interesting read. It would be great if this could be re-written [too much to ask I know ] or at least updated in the context of flash 10 or even flash 9 & AS3.

Submit a comment

Only registered members can comment. Click here to login or here to register