Optimizing FLA Files for SWF Output

SWF file performance is important, and you can improve performance when you create your FLA document—from how you write ActionScript code, to how you build animations. This section provides guidelines and practices that help improve the performance of your SWF file at runtime.

For more information on code optimizations for Flash Player, see ActionScript 2.0 Best Practices.

Optimizing Graphics and Animation

The first step in creating optimized and streamlined animations or graphics is to outline and plan your project before its creation. Specify a target for the file size and length of the animation that you want to create, and test throughout the development process to ensure that you are on track. If you are creating advertisements, for example, length and file size are extremely important.

Avoid using gradients, because they require many colors and calculations to be processed, which is more difficult for a computer processor to render. For the same reason, keep the amount of alpha or transparency you use in a SWF file to a minimum. Animating objects that include transparency is processor-intensive and should be kept to a minimum. Animating transparent graphics over bitmaps is a particularly processor-intensive kind of animation, and must be kept to a minimum or avoided completely.

Note: The best bitmap format to import into Flash is PNG, which is the native file format of Macromedia Fireworks from Adobe. PNG files have RGB and alpha information for each pixel. If you import a Fireworks PNG file into Flash, you retain some ability to edit the graphic objects in the FLA file.

Optimize bitmaps as much as possible without overcompressing them. A 72-dpi resolution is optimal for the web. Compressing a bitmap image reduces file size, but compressing it too much compromises the quality of the graphic. Check that the settings for JPEG quality in the Publish Settings dialog box do not overcompress the image. If your image can be represented as a vector graphic, this is preferable in most cases. Using vector images reduces file size, because the images are made from calculations instead of many pixels. Limit the number of colors in your image as much as possible while still retaining quality.

Note: Avoid scaling bitmaps larger than their original dimensions, because it reduces the quality of your image and is processor-intensive.

Set the _visible property to false instead of changing the _alpha level to 0 or 1 in a SWF file. Calculating the _alpha level for an instance on the Stage is processor-intensive. If you disable the instance’s visibility, it saves CPU cycles and memory, which can give your SWF files smoother animations. Instead of unloading and possibly reloading assets, set the _visible property to false, which is much less processor-intensive.

Try to reduce the number of lines and points you use in a SWF file. Use the Optimize Curves dialog box (Modify > Shape > Optimize) to reduce the number of vectors in a drawing. Select the Use Multiple Passes option for more optimization. Optimizing a graphic reduces file size, but compressing it too much compromises its quality. However, optimizing curves reduces your file size and improves SWF file performance. There are third-party options available for specialized optimization of curves and points that yield different results.

You have several options if you want to animate content in a Flash document. Animation that uses ActionScript can produce better performance and smaller file size than animation that uses tweens at times, but sometimes not. To get the best results, try different ways of producing an effect, and test each of the options.

A higher frame rate (measured in frames per second) produces smooth animation in a SWF file but it can be processor intensive, particularly on older computers. Test your animations at different frame rates to find the lowest frame rate possible.

Animation Frame Rate and Performance

When you add animation to an application, consider the frame rate that you set your FLA file to. You need to think about frame rate when working with animations because it can affect the performance of your SWF file and the computer that plays it. Setting a frame rate too high can lead to processor problems, especially when you use many assets or use ActionScript to create animation.

However, you also need to consider the frame rate setting, because it affects how smoothly your animation plays. For example, an animation set to 12 frames per second (fps) in the Property inspector plays 12 frames each second. If the document’s frame rate is set to 24 fps, the animation appears to animate more smoothly than if it ran at 12 fps. However, your animation at 24 fps also plays much faster than it does at 12 fps, so the total duration (in seconds) is shorter. Therefore, if you need to make a 5-second animation using a higher frame rate, it means you need to add additional frames to fill those five seconds than at a lower frame rate (and thus, this raises the total file size of your animation). A 5-second animation at 24 fps typically has a higher file size than a 5-second animation at 12 fps.

Note: When you use an onEnterFrame event handler to create scripted animations, the animation runs at the document’s frame rate, similar to if you created a motion tween on a timeline. An alternative to the onEnterFrame event handler is setInterval. Instead of depending on frame rate, you call functions at a specified interval. Like onEnterFrame, the more frequently you use setInterval to call a function, the more resource intensive the animation is on your processor.

Use the lowest possible frame rate that makes your animation appear to play smoothly at runtime, which helps reduce the strain on the end-user’s processor. Try not to use a frame rate that’s more than 30 to 40 fps; high frame rates put a lot of stress on processors, and do not change the appearance of the animation much or at all at runtime.

Also, especially if you’re working with timeline-based animation, select a frame rate for your animation as early as possible in the development process. When you test the SWF file, check the duration, and the SWF file size, of your animation. The frame rate greatly affects the speed of the animation.

Filters and SWF File Performance

One problem that arises if you use too many filters in an application is the potential to use large amounts of memory and cause Flash Player performance to suffer. Because a movie clip with filters attached has two bitmaps that are both 32-bit, these bitmaps can cause your application to use a significant amount of memory if you use many bitmaps. You might see an out-of-memory error generated by the computer’s operating system. On a modern computer, out-of-memory errors should be rare, unless you are using filter effects extensively in an application (for example, you have thousands of bitmaps on the Stage).

However, if you do encounter an out-of-memory error, the following occurs:

• The filters array is ignored.
• The movie clip is drawn using the regular vector renderer.
• No bitmaps are cached for the movie clip. After you see an out-of-memory error, a movie clip never attempts to use a filters array or a bitmap cache. Another factor that affects player performance is the value that you use for the quality parameter for each filter that you apply. Higher values require more CPU and memory for the effect to render, whereas setting the quality parameter to a lower value requires less computer resources. Therefore, you should avoid using an excessive number of filters, and use a lower quality setting when possible.

Caution: If a 100 pixel x 100 pixel object is zoomed in once, it uses four times the memory since the content’s dimensions are now 200 pixels x 200 pixels. If you zoom another two times, the shape is drawn as an 800 pixel x 800 pixel object which uses 64 times the memory as the original 100 pixel x 100 pixel object. Whenever you use filters in a SWF file, it is always a good idea to disable the zoom menu options from the SWF file’s context menu.

You can also encounter errors if you use invalid parameter types. Some filter parameters also have a particular valid range. If you set a value that’s outside of the valid range, the value changes to a valid value that’s within the range. For example, quality should be a value from 1 to 3 for a standard operation, and can only be set to 0 to 15. Anything higher than 15 is set to 15. Also, some constructors have restrictions on the length of arrays required as input parameters. If a convolution filter or color matrix filter is created with an invalid array (not the right size), the constructor fails and the filter is not created successfully. If the filter object is then used as an entry on a movie clip’s filters array, it is ignored.

Tip: When using a blur filter, using values for blurX and blurY that are powers of 2 (such as 2, 4, 8, 16, and 32) can be computed faster and give a 20% to 30% performance improvement.

Bitmap Caching and SWF File Performance

Flash Player 8 introduces bitmap caching, which helps you enhance the performance of nonchanging movie clips in your applications. When you set the MovieClip.cacheAsBitmap or Button.cacheAsBitmap property to true, Flash Player caches an internal bitmap representation of the movie clip or button instance. This can improve performance for movie clips that contain complex vector content. All of the vector data for a movie clip that has a cached bitmap is drawn to the bitmap, instead of to the main Stage.

Note: The bitmap is copied to the main Stage as unstretched, unrotated pixels snapped to the nearest pixel boundaries. Pixels are mapped one-to-one with the parent object. If the bounds of the bitmap change, the bitmap is re-created instead of being stretched.

It’s ideal to use the cacheAsBitmap property with movie clips that have mostly static content and that do not scale and rotate frequently. With such movie clips, using the cacheAsBitmap property can lead to performance improvements when the movie clip is translated (when its x and y position is changed). Enabling caching for a movie clip creates a surface, which has several advantages, such as helping complex vector animations to render fast. There are several scenarios in which you will want to enable caching. It might seem as though you will always want to enable caching to improve the performance of your SWF files; however, there are situations in which enabling caching does not improve performance, or even decrease it. The following section describes scenarios in which caching should be used, and when to use regular movie clips. Overall performance of cached data depends on how complex the vector data of your instances are, how much of the data you change, and whether or not you set the opaqueBackground property. If you are changing small regions, the difference between using a surface and using vector data could be negligible. You might want to test both scenarios with your work before you deploy the application.

When to Use Bitmap Caching

The following are typical scenarios in which you might see significant benefits when you enable bitmap caching.

• Complex background image: An application that contains a detailed and complex background image of vector data (perhaps an image where you applied the trace bitmap command, or artwork that you created in Adobe Illustrator). You might animate characters over the background, which slows the animation because the background needs to continuously regenerate the vector data. To improve performance, you can select the content, store it in a movie clip, and set the opaqueBackground property to true. The background is rendered as a bitmap and can be redrawn quickly, so that your animation plays much faster.
• Scrolling text field: An application that displays a large amount of text in a scrolling text field. You can place the text field in a movie clip that you set as scrollable with scrolling bounds (the scrollRect property). This enables fast pixel scrolling for the specified instance. When a user scrolls the movie clip instance, Flash shifts the scrolled pixels up and generates the newly exposed region instead of regenerating the entire text field.
• Windowing system: An application with a complex system of overlapping windows. Each window can be open or closed (for example, web browser windows). If you mark each window as a surface (set the cacheAsBitmap property to true), each window is isolated and cached. Users can drag the windows so that they overlap each other, and each window doesn’t need to regenerate the vector content.

All of these scenarios improve the responsiveness and interactivity of the application by optimizing the vector graphics.

When to Avoid Using Bitmap Caching

Misusing this feature could negatively affect your SWF file. When you develop a FLA file that uses surfaces, remember the following guidelines:

• Do not overuse surfaces (movie clips with caching enabled). Each surface uses more memory than a regular movie clip, which means that you should only enable surfaces when you need to improve rendering performance.
• Do not overuse bitmap caching. A cached bitmap can use significantly more memory than a regular movie clip instance. For example, if the movie clip on Stage is 250 pixels x 250 pixels in size, when cached it might use 250K instead of 1K when it’s a regular (uncached) movie clip instance.
• Avoid zooming into cached surfaces. If you overuse bitmap caching, a large amount of memory is consumed (see previous bullet), especially if you zoom in on the content.
• Use surfaces for movie clip instances that are largely static (nonanimating). You can drag or move the instance, but the contents of the instance should not animate or change a lot. For example, if you rotate or transform an instance, the instance changes between the surface and vector data, which is difficult to process and negatively affects your SWF file.
• Avoid mixing surfaces with vector data. If you mix surfaces with vector data, it increases the amount of processing that Flash Player (and sometimes the computer) needs to do. Group surfaces together as much as possible; for example, when you create windowing applications.

Working with Components in Flash Player

The component framework enables you to add functionality to components, but it can potentially add considerable file size to an application. Components inherit from each other. One component adds size to your Flash document, but subsequent components that use the same framework do not necessarily add more size. As you add components to the Stage, the file size increases, but at some point, it levels off because components share classes and do not load new copies of those classes.

If you use multiple components that do not share the same framework, they might add substantial file size to the SWF file. For example, the XMLConnector component adds 17K to the SWF file, and TextInput components add 24K to your document. If you add the ComboBox component, it adds 28K, because it is not part of either framework. Because the XMLConnector component uses data binding, the classes add 6K to the SWF file. A document that uses all these components has 77K before you add anything else to the file. Therefore, it is a good idea to carefully consider your SWF file size when you add a new component to the document.

Components must exist in the parent SWF file’s library. For example, a screen-based application must have a copy of the components it uses in its library, even if those components are required by child SWF files that are loaded at runtime. This is necessary to ensure that the components function properly, and slightly increases the download time of the parent SWF file. However, the parent library isn’t inherited or shared in the SWF files that you load into the parent. Each child SWF file must download to the application with its own copy of the same components.

When you are planning to publish a SWF file with backward compatibility, you must have a good understanding of which components have that capability. For information about component availability in different versions of Flash Player, see Table 3.

* Deselect the Optimize for Flash Player 6r65 option in Publish Settings for these components to work.

Optimizing Component Styles and Performance

One of the most processor-intensive calls in a component framework is the setStyle call. The setStyle call executes efficiently, but the call is intensive because of the way it is implemented. The setStyle call is not always necessary in all applications, but if you use it, you should consider its performance impact.

To enhance performance, you can change styles before they are loaded, calculated, and applied to the objects in your SWF file. If you can change styles before the styles are loaded and calculated, you do not have to call setStyle.

The recommended practice to improve performance when using styles is to set properties on each object as objects are instantiated. When you dynamically attach instances to the Stage, set properties in initObj in the call that you make to createClassObject(), as the following ActionScript shows:

createClassObject(ComponentClass, "myInstance", 0, 
  {styleName:"myStyle", color:0x99CCFF});   

For instances that you place directly on the Stage, you can use onClipEvent() for each instance, or you can use subclasses (recommended).

If you must restyle your components, you can improve efficiency in your application by using the Loader component. If you want to implement several styles in different components, you can place each component in its own SWF file. If you change styles on the Loader component and reload the SWF file, the components in the SWF file are recreated. When the component is recreated, the cache of styles is emptied, and the style for the component is reset and referenced again.

Note: If you want to apply a single style to all instances of a component in your SWF file, change the style globally using _global.styles.ComponentName.

Using Runtime-Shared Libraries

You can sometimes improve download time by using runtime-shared libraries. These libraries are usually necessary for larger applications or when numerous applications on a site use the same components or symbols. By externalizing the common assets of your SWF files, you do not download classes repeatedly. The first SWF file that uses a shared library has a longer download time, because both the SWF file and the library load. The library caches on the user’s computer, and then all the subsequent SWF files use the library. This process can greatly improve download time for some larger applications.

Displaying Special Characters

Computer systems have a specific code page that is regional. For example, a computer in Japan has a different code page than a computer in England. Flash Player 5 and earlier versions relied on the code page to display text; Flash Player 6 and later versions use Unicode to display text. Unicode is more reliable and standardized for displaying text because it is a universal character set that contains characters for all languages. Most current applications use Unicode.

You can use Unicode escape sequences to display special characters in Flash Player 6. However, it is possible that not all your characters display correctly if you do not load text that is UTF-8 or UTF-16 encoded (Unicode) or if you do not use a Unicode escape sequence to display the special character. Table 4 shows a list of commonly used escape sequences.

A non-Unicode application uses the operating system’s code page to render characters on a page. In this case, the characters you see are specified by the code page, so the characters appear correctly only when the code page on the user’s operating system matches the application’s code page. This means that the code page that was used to create the SWF file needs to match the code page on the end user’s computer. Using code pages is not a good idea for applications that might be used by an international audience; in this case, use Unicode instead.

Using System.useCodepage in your code forces the SWF file to use the system’s code page instead of Unicode. Only use this process in the following situations: when you are loading non-Unicode encoded text from an external location and when this text is encoded with the same code page as the user’s computer. If both these conditions are true, the text appears without a problem. If both of these conditions are not true, use Unicode and a Unicode escape sequence to format your text. To use an escape sequence, add the following ActionScript on Frame 1 of the Timeline:

this.createTextField("myText_txt", 99, 10, 10, 200, 25); 
myText_txt.text = "this is my text, u00A9 2004";   

This ActionScript creates a text field, and enters text that includes a copyright symbol (©). You can make a SWF file use the operating system’s code page, which is controlled by the useCodepage property. When Flash exports a SWF file, it defaults to exporting Unicode text and System.useCodepage is set to false. You might encounter problems displaying special text, or text on international systems where using the system’s code page can seem to solve the problem of text incorrectly displaying. However, using System.useCodePage is always a last resort. Place the following line of code on Frame 1 of the Timeline:

System.useCodepage = true; 

Caution: The special character displays only if the user’s computer has the character included in the font that is being used. If you are not sure, embed the character or font in the SWF file.