Adobe 65018518 User Guide - Page 447

USING FLASH CS4 PROFESSIONAL 442 Best practices Optimizing component styles and performance When using ActionScript 2.0, 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, consider its performance effect. 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. To improve performance when using styles, 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 Learning ActionScript 2.0 in Adobe Flash. If you must restyle your components, you can improve efficiency in your application by using the Loader component. To implement several styles in different components, 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: 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 operating 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 and later. However, 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. For a set of Unicode code charts, see the Unicode web site at Unicode.org. For a list of commonly used escape sequences, see the table that follows in this section. A non-Unicode application uses the operating system's code page to render characters on a page. In this case, the code page specifies the characters you see, so the characters appear correctly only when the code page on the user's operating system matches the application's code page. 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 an international audience might use; in this case, use Unicode instead. Updated 5 March 2009