Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript

Web Topics
All Articles
Scripting Languages

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab

O'Reilly Book Excerpts: Flash Hacks

Hacking Flash, Part 2

Editor's note: Today we offer two more hacks excerpted from O'Reilly's Flash Hacks. Learn how to create a performance budget that shows where your money is going, and how to secure your online Flash content. And if you missed them, be sure to check out last week's hacks from the book.

Expert Hack #71

Performance Budget

A financial budget tells you where you are spending your money. Create a performance budget to understand and adjust where you are expending resources

We saw earlier how to estimate download times , allowing you to cram the maximum presentation into the smallest filesize. Performance has a lower priority in the Flash Player design than does filesize optimization, which means that although Flash allows you to create compelling content in very few kilobytes, you have limited resources from which to extract performance. Although the total processor cycles available to the Flash Player are limited, you can control where Flash spends its time. A performance budget reflects a conscious effort to adjust the amount of time Flash doles out to each of the parts of your movie.

Related Reading

Flash Hacks
100 Industrial-Strength Tips & Tools
By Sham Bhangal

Areas of Focus

Like all budgets, your performance budget should include priorities. That is, not all aspects of your presentation are equally important. For example, users notice hiccups in audio tracks more than hiccups in videos or animation. Designers also tend to lavish attention on things the typical user won't ever notice or appreciate. The user generally looks closely only at the things she is currently interacting with; elements within the user's "area of focus" get the greatest attention from her and therefore should be given priority in your performance budget. Items in the user's peripheral vision may be ignored entirely or noticed only when they do something unexpected, such as shift by a pixel. Therefore, allocating your performance budget and designing an interface that serves the user's needs are complementary tasks.

If you can anticipate (or control) the user's area of focus, and make that perform well, the user gets the impression of greater overall performance even if peripheral items are static or perform less well.

For example, in video games (and intensive real-time graphics), items closest to the viewer in the 3D virtual world are rendered with the most detail. The detail can drop off significantly with distance; even if the player notices, it mirrors reality in which things further away are generally less visible/detailed. Likewise, the collision detection algorithm used by distant parts of the game can be less precise for the same reason—they are not close enough to be in the user's area of focus. This allowance frees up some of the performance budget for real-time lighting, physics, and other trappings of virtual worlds.

Set Process Priorities

There are a number of ways to give your area of focus the lion's share of the performance budget. The easiest approach is to simply give the area of focus an "on-change" event handler and use a periodic event to update the rest of the movie. For example, if you are implementing a pong game, you can use an onMouseMove( ) event handler to control the user's paddle and an onEnterFrame( ) event handler to control the opponent's paddle and the ball. If the part of the game that the user controls is responsive, the entire application feels more responsive.

However, just setting two different priorities doesn't allow us detailed control over the performance budget. A better approach is to use several different priorities. Here we allocate our priorities based on the likelihood and directness of user interactivity:

High priority

Processes with which the user will interact directly

Normal priority

Processes with which the user will interact indirectly

Low priority

Processes with which the user will rarely or never interact

In terms of a game (the most common high-performance Flash application), the high-priority process is the player's ship or character (a.k.a. token). Normal-priority processes include the enemy graphics; although the user expects them to move at an adequate speed, the slowdown won't be as noticeable as long as the high-priority stuff doesn't slow down as well. The user will just assume that the slow-moving enemy target is supposed to move slowly.

Low-priority processes are things like the score update or a scrolling background—the user notices if they break, but if they work adequately, the user pays little attention.

Low-priority processes can be hard for game designers to identify because developers are personally vested in every pixel and audio cue. You'll be more apt to let go of your rigidly held beliefs if you realize that everything you deprioritize allows you to lavish more attention (or performance) on things that matter more. And don't forget that the sound effect that was cute the first time might get really boring after the user hears it a thousand times. So the best option is to put your prototype version in front of beta testers. Ask them what they like, what seems too slow, what they find annoying, and so on. By definition, these are the people you are trying to entertain, attract, or serve, so listen to their feedback.

You can also trick your audience into thinking you are doing more than you actually are. For example, you can have a scrolling star field with many stars when the game is displaying the static high score table, but as soon as the game starts, you can reduce the animation complexity . The user won't notice if you slowly drop the number of stars as the game gets faster and more difficult. He is more likely to be concentrating on getting to the next level!


Once you decide on your priorities, you need to implement them in ActionScript. Since you can't just tell Flash that something is important, you instill priorities indirectly via the programming techniques and events you choose.

High-priority events can use either: