Changes to the Macromedia Flash Asset Xtra in Director MX 2004

Using the Common Player

The new commonPlayer property lets multiple Macromedia Flash cast members share a single instance of the Flash asset during playback. In past versions of the Flash Asset Xtra, each Flash sprite required a separate instance of the Flash asset (player) to be created in order to render the sprite(s). Since each Flash asset instance reserves a significant chunk of memory, the amount of memory and processor power required to maintain a large number of separate Flash player instances could compromise performance in some movies. The commonPlayer property resolves these performance issues by letting multiple independent Flash cast members share a common instance of the Flash player.

Figure 4. commonPlayer property for a Flash cast member

The commonPlayer property is associated with all cast member types that utilize the Flash asset for rendering, these include:. vector shape cast members, Flash swf members and Flash components. Only standard Flash swf cast members have a commonPlayer property that is settable through the Property Inspector. By default, the commonPlayer property is set to the symbol #none for Flash and Flash Component members and it is set by default to #vectorShape for vector shape members. When set to #none, the cast member will render using its own instance of the Flash asset. Vector shape members will render using a common player instance named #vectorShape. The commonPlayer property is a cast member property and not a sprite property. However, if changed at runtime, the change will affect all new instances of the Flash cast member but will not affect those instances of the member that have already created. During authoring, it will affect all instances that were previously created when the movie is stopped and restarted. The commonPlayer property is saved with the member data when the Director movie is saved and its last value is remembered between authoring sessions.

To set the commonPlayer property for Flash cast members and deriviative member types, use the following syntax:

Lingo:

member("someFlashMember").commonPlayer = #somePropertyName

JavaScript Syntax:

member("someFlashMember").commonPlayer = symbol("somePropertyName");

When setting the commonPlayer property, use must use a symbol regardless of whether using Lingo or JavaScript Syntax. All members that share the same symbol value for the commonPlayer property will render using the same player. The commonPlayer is not the answer for all situations where multiple Flash sprites appear simultaneously on stage.

As meantioned above, using a common player instance is not always a good thing, in cases where you have very ActionScript heavy swf files, you may find that sharing the same common player instance with another swf file may cause conflicts. Due to the heavy use of ActionScript by Flash Components, these members have difficulty sharing a common player instance without conflict. Its important to understand how the commonPlayer property works in order to evaluate whether it is applicable to you.

When two or more Flash members share the same instance of the Flash asset, each instance of the Flash member(s) is loaded into a different level of the common Flash player instance. The process is very similar to having a single swf file into which each cast member instance gets loaded into a seperate level using loadMemberNum syntax of ActionScript. Each sprite (instance) of a Flash member that uses a common player has a level property that can be used to identify the level in which the swf file is loaded. This level property corresponds to the appropriate _level property of a standard Flash movie.

theLevel = sprite(x).level

While the mechanism of sharing a common player instance is nearly identical to using loadMovieNum in ActionScript, it should be noted that Director allows each Flash sprite to maintain its own properties and behaves independently such as quality, framerate etc. So there is both similarity and differences between Flash's loadMovieNum and Director's handling of a common player instance.

There are several factors that would suggest that a set of cast members should not be used with a common player instance:

• heavy use of ActionScript
• movies that load other movies into levels using loadMovieNum
• complex swf files that utilize a wide array of UI elements

While the following factors might indicate a good use of the commonPlayer property:

• simple Flash UI elements such as simple buttons
• static Flash members that appear simultaneously on screen
• Flash member instances that might need to share common variables at runtime

As mentioned above, it may be possible to share some variable data between Flash asset instances sharing the same commonPlayer property. However, it would be extremely prudent to test this behavior heavily before committing to building a project that relies on this type of functionality.

The commonPlayer property has the potential to seriously improve performance of movies that make heavy use of Flash assets. As with any new feature, it is adviseable to heavily test and compare the results of using and not using the commonPlayer property to ensure that it matches your particular needs. Much of the information above comes from correspondance with Dan Sadowski and other members of the Director development team.

Page 4 of 8

Previous Page

Next Page