Performance and optimization of graphics rendering in Flash

During the creation of our game on flash (caution - VKontakte!), At some point we were faced with a performance problem.

FPS began to fall even on highly productive systems ... The problem was typical of all flash games - a large amount of vector graphics. As you understand, vector graphics are a very resource-intensive thing. After all, when rendering a player, it is necessary to re-calculate various tricky curves, etc., which clearly loses in speed with raster graphics. With that - loses an order of magnitude (or even several orders of magnitude).

According to the good old tradition, Google was taken in the mouth and the search for a solution began ...

Regular solution

The first thing you stumble upon is “cache as bitmap”. Let's first deal with this option.
')
Enable this option is necessary for each clip separately. This is done either in Flash itself - by selecting a clip, on the “Properties” panel by installing the check mark of the same name. Or dynamically - in the AS3 code by setting the MovieClip's “cacheAsBitmap” property to “true”.

Turning on this mode, we tell Flash to save our vector MovieClip in memory as a bitmap image and then, if necessary, display it on the screen - it’s already displayed as a raster, which gives a noticeable performance boost.

The question arises - why then this method is not enabled by default?

It's simple. The fact is that if the cached clip changes (animated), or you want to rotate / scale / change the transparency, in order for this to happen, the flash will have to revert to the vector “source code” of the clip to cache the already updated image. Thus, if we have a clip that changes every frame, then the player will have to constantly rehash it, which, on the contrary, will lead to a drop in performance.

In short, the “cache as bitmap” can be safely enabled for all static movie clips. If, for example, you have a background in the game that consists of a static substrate and animated clips (for example, moving plants superimposed on a static forest landscape), then you should separate the static part into a separate movie and set up caching for it.

So, what's good / bad about this method:
+ Enable method to ugliness is simple. In addition, the user will not detect any difference in viewing (micro-nuances can occur only when using non-integer coordinates of the clip).
+ The method is ideal for static movie clips of any complexity (with any number of gradients, curves, etc.)
- The method should not be used for animated, rotating, clips, as well as clips with varying transparency. Naturally, you will not get any graphic artifacts - everything will still be beautiful. But you can do the opposite - lose.
- The method eats away some amount of memory (well, without this - nowhere ... should the player somewhere store a rasterized image).
- According to the testimonies of some developers, with large clips (10,000 x 10,000) there may still be a slowdown.

Solution for animated clips.

It turns out that for animated clips there is also a solution. The essence of this decision is to take an animated clip and rasterize all its frames in advance and store them as bitmapData. And then operate with a clip-raster copy of the original.

You say it is difficult? In fact, the bike has already been invented before us. You can use a ready-made solution posted on the Touch My Pixel blog. There is also an online example that allows you to evaluate the performance of the method.

The difference in using and not using animation caching is quite significant:



Pros and cons of this method:
+ The method is suitable for animated clips and allows you to significantly improve performance.
- The decision is not out of the box, i.e. It is necessary to "fasten" the third-party code.
- The method requires pre-rendering of the entire animation (i.e., a slight delay before the flash drive starts).

Result.

Our graphics is something like this:

(the monster in the center is created by the user, so do not hit him for his “prettiness” :)

As a result of the inclusion of a regular “cache as bitmap” for static, FPS, which fell to as much as 12, rose to a regular 30.

Now we think how to correctly apply caching for animated graphics.

Conclusion

I hope this article will help you improve the performance of your flash drives!

Useful materials on the topic:

• The article by Anton Karlov about animation performance - experiments with the above class for rasterizing animated clips are just described here
• Why cacheAsBitmap is bad - another article about cacheAsBitmap and auto-rasterization.