Flash log en "La Nube"
In already-finished proyects, the largest(and easiest) performance gains in Flash are to be made by adjusting the overall quality of the renderer, because this practice doesnt require to change anything inside the proyect.
In the ideal case, Quality settings should be left in the highest possible setting so the app would take advantage of flash´s clear and well-defined graphics, Therefore lowering the overall quality must be a last resort after all other possible optimizations have been done.
Flash quality adjustments affect primarily image Anti-Aliasing(covered next), which is a time consuming but rewarding visual effect applied to everything that Flash renders.
NOTE: Flash´s default display quality is “HIGH”;
Anti-aliasing(AA) works in the same way for flash as it does for other applications. It consists in a complex process of adding mid tone pixels to the jagged edges of images or text so the human eye will perceive a smoother image instead of jagged lines that look like a ladder.
Highest levels of AA in more complicated applications even tune alpha values in these pixels to further increase the (apparent) quality of the lines. Complicated as it is, this process is costly for the CPU, and adds lots of work to the rendering cycles. This applies to both image and text rendering.
Anti-Aliasing (quality) levels:
•StageQuality.LOW—Low rendering quality. Graphics are not anti-aliased, and bitmaps are not smoothed.
•StageQuality.MEDIUM—Medium rendering quality. Graphics are anti-aliased using a 2 x 2 pixel grid, but bitmaps are not smoothed.
•StageQuality.HIGH—High rendering quality. Graphics are anti-aliased using a 4 x 4 pixel grid, and bitmaps are smoothed if the movie is static.
•StageQuality.BEST—Very high rendering quality. Graphics are anti-aliased using a 4 x 4 pixel grid and bitmaps are always smoothed.
The “CacheAsBitmap” flag:
When you ask Flash to use cacheAsBitmap on an image, it stores a copy of the vector image´s point array in memory (for swapping), but uses a converted version (converted to bitmap) for rendering, so the vector image doesnt need to be calculated and redrawn every frame. Thanks to the saved point array, display objects can be swapped to and from bitmap format as much as one needs.
USAGE: Use on complex vector images that don’t transform, for example complex background images (moving or not), non-animated sprites and most user interface elements.
ADVANTAGES: Bitmaps, unlike vectorial images, are not recalculated on every frame by the flash player unless they suffer a transformation. Thanks to this, cacheAsBitmap allows for some performance gains when handling static and complex vectorials.
WARNING: Animated (transforming) objects are going to be redrawn regardless if they are bitmaps or vectors, so using CacheAsBitmap on animated Sprites or MovieClips would actually make it slower than a vector, forcing flash to recalculate the vectorial image, redraw it, save it and get the bitmap copy done once every frame for as long as the object is being changed internally.
Vectors are mathematical representations of images and they store only numerical values needed to draw the image from scratch, and therefore have the advantage of being very small in size, which is very useful for saving bandwidth.
The problem with vectors is that all advantages in size then become disadvantages in processing requirements. The format of vector images means that flash will draw the image from scratch in each rendering cycle (frame). This is an increased load if you compare it with bitmaps:
Flash has to calculate the vector´s nodes and resolve pixel positions in addition to drawing pixels in their places. With Bitmap Images, only the latter is done, and therefore less processor time is consumed in the rendering cycle. You can improve this through AS3 by using the CacheAsBitmap flag in DisplayObjects. This will require flash to calculate the pixels only once, and then (as long as the vector doesnt change) draw it as if it were a common bitmap image. More on this on the next section.
We know that scaling bitmaps is avoided at all cost by Flash developers because of the serious loss of image quality it brings.
On the other hand, we know that scaling a Vector image is very easy to do and there is no loss of quality. In fact, because Vectors are rendered at runtime, you can scale a vector to be many times larger than its original size and still have defined lines and good looking color fills.
All this definition has its price in terms of CPU consumption, and the larger the amount of scaled vectors on-screen is, the bigger the burden on the Processor will be. Keep this in mind when scaling vectors: some is O.K., but f you need to scale the whole stage, consider redrawing the vectors or scaling its individual internal parts.
Resolution & redraw regions:
Generally, the performance bog-downs in Flash are reduced to how much is being rendered at a specific moment, namely, what percentage of the screen is being redrawn. The larger the size of the screen, the larger the quantity of pixels that flash has to redraw each frame, so in all aspects, a 800×600 flash app will be slower than a smaller one.
Apart from this, the size of independant redraw regions will also influence the performance rates. This means that in some cases a complicated but small image(a small star or a drawing of a person) may be easier for flash to render than a much simpler but much larger shape ( maybe a square or rectangle). Also, rendering small things in the edges of the screen could potentially enlarge the general redraw region, giving flash more work to redraw a whole frame.
Because of these two things, it is always a good practice to keep both overall app. Resolution and redraw region sizes as small as possible, as well as trying to avoid animations & effects on the edges of the screen.