Performance traps in Flash Player 8

No question, everyone is excited about this release of the Flash Player. The new features definitely offer something which has never been seen before on the web. But, as with any new technology it can be overused. There are reasons why the Flash Player did not offer these advanced feature in earlier releases. One of them was the lack of client machines out there being able to handle the CPU load some of these new features will require. I am scheduled to write two articles about this for DevNet to point out the limitations. You will almost certainly run into these also. Here is quick summary:

• The On2 VP6 codec roughly uses about twice the resources than Sorenson Spark codec. This includes CPU usage and memory usage. Better quality simply means more complexity on the decoding side. At least The On2 VP6 codec is still running on slower machines compared to the QuickTime 7 H.264 codec (which really has outrageous hardware requirements).


• Alpha channel video is very complex. One of the most common mistakes which will be made is that users will make the assumption that fully transparent areas will not impact on CPU usage. This is not the case, the codec has no clue which areas are transparent, still needs to decode them AND compose them. There is a strong need to clip out as much of the transparent areas as possible. Even our marketing team ran into this when they put together the Studio Experience. Some of the alpha channel videos were something like 640x350 pixels large, although it does not look like it. This is way too large for older Macs to handle. There are some tricks you can use to get around some of these problems, but they are difficult to author.
  
  Overall alpha channel video is about 4 times more complex than decoding video without alpha channel (That also means that alpha channel video is about 6-8 times slower than Sorenson Spark video overall). Why is that? The Flash Player, in addition to decoding the normal video needs to decode a separate alpha channel and then needs to do compositing against the background. Especially the latter step is extremely expensive, despite the fact that we use MMX and AltiVec for this. If there is no alpha channel we can decode directly into the bitmap buffer which is not possible when an alpha channel is present.


• The blur filter, drop shadow, bevel and glow filters are mostly limited by memory bandwidth as are many other filters. Like I explained in the previous post there is nothing more we can do performance wise in this release. Keep this in mind and make sure you test your content on the slowest machine you want to have your content working. I usually use an old black PowerBook G3 to test since these are the slowest machines which are mostly likely to be still in use. Even better, why not author your Flash files on that machine? Cumbersome, but at least you'll see the problems instantly. Too many times I have seen emails from angry customers authoring their content on their lastest and fastest Pentium 4 and then wondering why the performance sucks on an old machine. Gimme a break... Doom 3 won't run on a Pentium I 90Mhz either.


• There is a new feature called 'Show redraw regions' in the Flash Player which will allow you to see which areas of your movie are refreshed every frame. Use it extensively to keep the areas as small as possible.

Be smart when you employ filters, effects and video. It's good to spice up content with them, but usually a more subtle use of them is better than overloading your animations with bling bling. We really do not need another 'Skip Intro' era do we? :-)