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.

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. For detailed
information, see "Animation Frame Rate and Performance".

For information on best practices and video, see "Video Conventions". For an example of scripted animation, see the animation.fla
example in the Samples and Tutorials/Samples/ActionScript/Animation directory within the Flash installation folder.

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. See setInterval
Function in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Global
Functions > setInterval Function). 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.

For detailed information on caching button or movie clip instances see the following sections in Flash Help or the Flash 8 LiveDocs:

• About Caching and Scrolling Movie Clips with ActionScript (Learning ActionScript 2.0 in Flash > Working with Movie Clips > About
Caching and Scrolling Movie Clips with ActionScript)
• Caching a Movie Clip (Learning ActionScript 2.0 in Flash > Working with Movie Clips > About Caching and Scrolling Movie Clips
with ActionScript > Caching a Movie Clip)
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.

Table 3. Component Availability in Flash Player

Components Flash Player 6 (6.0.65.0) Flash Player 6 Flash Player 7
and Earlier (6.0.65.0) and Later
ActionScript Supported Supported Supported
2.0
V2 UI Not supported* Supported Supported
component set
Media Not supported Not supported Supported
components
Data Not supported Not supported Supported
components
* 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). For information on subclasses, see About Writing a Subclass in Flash Help or the Flash 8 LiveDocs (Learning
ActionScript 2.0 in Flash > Inheritance > About Writing Subclasses in Flash > About Writing a Subclass).

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. For a set of Unicode code charts, see the
Unicode Character Code Charts By Script website.

Table 4. Commonly Used Unicode Escape Sequences

Character Description Unicode Escape Sequence
em-dash (—) \u2014
registered sign (®) \u00AE
copyright sign (©) \u00A9
trademark sign (TM) \u2122
Euro sign (€) \u20AC
backslash (\) \u005C
forward slash (/) \u002F
open curly brace ({) \u007B
close curly brace (}) \u007D
greater than (<) \u003C
less than (>) \u003E
asterisk (*) \u002A
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.