This website uses cookies to improve user experience. By using our website you consent to all cookies in accordance with our Cookie Policy. X

Understanding the "Graphics" symbol

Anyone who already spent some quality time in ActionScript is no doubt fully aware what MovieClips do or how they work, however Flash also allows for creation of something very similar, the symbols called "Graphics". At first they might seem like a simplified versions of MovieClips, which is of course true but their existence relies on much simpler rule... during the exporting process all "Graphics" symbols are split into pieces, similar to how the "break apart" command (CLTR+B) does it, with only difference being that all properties and tweens are applied to objects within. From the ActionScript's perspective this gives us an interesting ways of optimization by removing excessively nested MovieClips.
For example lets take a scenario where we want two objects to be circling around each other and also at the same time both of them smoothly relocated to a new position:

So the Anim symbol contains the animation of two circling objects, while on the stage both of them are being moved to a new location. Nothing interesting here yet, but if we decide we want access to both of those objects from ActionScript instinctively the first step will be to switch Anim from "Graphics" into "MovieClip" and than followed by giving it an instance name so we can navigate through it to access the two objects we want. Which is exactly the nesting we can avoid by using the Graphics - of course if we know how they work.
I suggest experimenting with this by yourself, starting by creating two MovieClips on the stage with two different key-frames within them, then name them "mc1" and "mc2" (instance names, so you can access them from ActionScript) and finally enclose the whole thing inside a Graphics symbol. What will happen if we call the following script from the Stage's timeline?
mc1.gotoAndStop(1);
mc2.gotoAndStop(2);
Because the Graphics symbol will be broken apart with MovieClips "mc1" and "mc2" being thrown outside, the script will execute correctly.
A ready example for download: GraphExample.zip

Top 5 things that kill Flash's framerate.

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:
1. Filters.
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.