Adobe Flash Professional CC 2014 v.13.0 - Manual (Page 859)

To the top
Enabling caching for a movie clip creates a surface, which has several advantages, such as helping complex vector animations to render
fast. In some situations, enabling caching does not improve performance, or even decrease it.
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 might be negligible. 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 by optimizing vector graphics.
Complex background image An application that contains a detailed and complex background image of vector data. To improve performance,
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 faster.
Scrolling text field An application that displays a large amount of text in a scrolling text field. Place the text field in a movie clip that you set as
scrollable with scrolling bounds (the scrollRect property), enabling fast pixel scrolling for the specified instance. When a user scrolls the movie clip
instance, the scrolled pixels shift up and generate 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.
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 Professional 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 components 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:
Components Flash Player 6
(6.0.65.0) and earlier Flash Player 6
(6.0.65.0) Flash Player 7 and 8 Flash Player 9
ActionScript 3.0 Not supported Not supported Not supported Supported
ActionScript 2.0 Supported Supported Supported Supported
V2 UI component set Not supported Supported Supported Supported
Media components Not supported Not supported Supported Supported
852