Without a doubt most of us heard that Flash might be slow at times and even thought with each version it gets faster and faster, there are still games out there that might bring even most powerful PC to its knees. Surprisingly enough it might not necessarily be the programmers fault, but actually those inconspicuous graphic designers doing - that's right, ActionScript (especially 3) is already so fast, its contribution to the slowdowns might be marginal compered to some graphically intensive designs. That is why it is time to give those programmers a break and check if we accidentally aren't using any of the 5 most demanding graphics elements:
Undisputed winner in Flash slow downs, one unfortunately placed filter can turn a smooth animation into a slide show. Not to get into too much details, any MovieClip that has a filter applied to it stops being a vector graphic and is instead turned into a bitmap - with bitmap itself not being a problem but rather the process of creating one. Which is why you need to remember those two things when working with bitmaps:
- avoid bulky graphics (no bigger than average website banner)
- avoid filtered animations (for reasons stated below in: "cache as bitmap")
2. Cache as bitmap.
I must say bitmaps in Flash are quite intriguing; for example lets take simple a red rectangle drawn in vector graphic and in a bitmap - in this case Flash will display the vector one much faster than the bitmap one. However, start filling that rectangle with decorations, patterns or gradients and soon enough it will turn out that the bitmap solution is the faster one. Where lies the boundary? Well, that is something everyone should find out on their own, but generally just adding a simple gradient makes for a good reason to go with the "cache as bitmap" option. Unfortunately, every rose has its thorn... bitmaps can bring great speedups but also massive slowdowns, as even a simple transformation (changing colors, scaling, rotation) might bring devastating results. So when working with bitmaps always remember:
- cache as bitmap is completely pointless on animated MovieClips.
- bitmaps and cached MovieClips are very slow with any kind of transformations.
- if you must, it is much better to transform a real bitmap rather than a MovieClip with "cache as bitmap".
3. Alpha (transparency).
Yeah I know, "give up on transparency? Forget it!" Even so there is a good reason why it takes a third place on this list - this silent assassin doubles the amount amount of time needed to draw a pixel on the screen for each transparent bit. So whenever possible, instead of yet again making another semi-transparent shape to serve as a shadow, actually take a moment to really shade the background graphics.
4. Excessive amount of MovieClips.
It is very easy to get accustom to the possibilities that MovieClips provide, since they are so easy to swap around, edit without affecting outside elements and most importantly clone to bring infinite details into scenes. Of course those features don't come without a price and we have to pay with performance. Each MovieClip on a scene added not only new graphics but also ton of parameters: position, scale, filters, colors, name, visibility, caching etc. and even thought you might not be using them at all, all of them are processed on each frame of animation. Whenever possible try to replaces MovieClips with Graphic objects (or better yet just Shapes).
5. Hidden objects.
In other words everything that we don't, but it is still there. The worst case example of this is masking, as everything under them is still rendered on the screen but afterwards only cut down to fit the designed boundaries . The exact same thing happens with Flash's display area, which also doesn't remove anything, which means every object on the scene impacts the performance the exact same way, no matter on screen or not.