FLASH CS3
User Guide
489
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.
When to avoid using bitmap caching
Misusing bitmap caching can 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; only enable surfaces to improve rendering performance.
•
A cached bitmap can use significantly more memory than a regular movie clip instance. For example, if the movie
clip on the Stage is 250 pixels by 250 pixels, when cached it might use 250 KB instead of 1 KB when it's a regular
(uncached) movie clip instance.
•
Avoid zooming in on 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.
•
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; for example, when you create windowing applications.
Working with components in Flash Player
The component framework lets you 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 the framework
of either previous component. 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. 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, an application must have a copy of the compo-
nents it uses in its library, even if those components are required only 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. The following table provides information about component availability in
different versions of Flash Player:
