What's an error and why does it keep following me?

One of the first things I noticed when I started working in ActionScript 3 is that it's far less forgiving than ActionScript 2 when it comes to output errors. Ultimately, this is a good thing, which I've become used to and even use to my advantage. But it's a different experience than working in ActionScript 2, that's for sure.

This section is intended to give you a broad overview of the types of Adobe Flash Player issues you'll deal with and how they are visualized in the Flash CS4 workspace.

Understanding the ActionScript 3 environment

The ActionScript 3 architecture runs on a new engine (ActionScript Virtual Machine 2) which removes many of the legacy issues that have accumulated in previous versions of Adobe Flash. The update is dramatic enough that it requires a new file format that can be viewed in Flash Player 9 and later.

For a technical overview of the new ActionScript engine, please read the following paper:

• ActionScript Virtual Machine 2 (AVM2) Overview (PDF, 400K)

In Flash CS4, the ActionScript 3 environment exists in two parts: the ActionScript 3 FLA file and the ActionScript 3 programming language.

By default you're working with an ActionScript 3 FLA file when you create a new file in Flash CS4. The look of the elements in the file and the general experience is the same as it is with an ActionScript 2 FLA file, but the Flash CS4 workspace updates to show ActionScript 3 features when an ActionScript 3 FLA is in focus. Most notably, you'll see that the set of components is different in the Components panel.

When working with an ActionScript 3 FLA file, managing assets and creating symbols is pretty much the same process that you're used to in ActionScript 2, but the rules for coding change a bit. Code can be added to keyframes along your timelines or linked to the main timeline or your symbols using external ActionScript files. (Code can no longer be attached to instances on the Stage.)

When you publish your movie, the ActionScript code is compiled into the resulting SWF file. The ActionScript 3 compiler processes the ActionScript code by checking to make sure that the structure of the code and code assignment all match the strict rules of the ActionScript 3 language.

More often than not, you'll deal with errors at compile time whenever you publish the movie.

Understanding what an error is

Errors are notifications built into the ActionScript language and compiler process. Errors come in three flavors: compiler errors, runtime errors (ActionScript exceptions or error events), and warnings:

Compiler errors are generated when the file is published and the ActionScript is compiled into a SWF file. Compiler errors enforce rules that allow the ActionScript code to run in an optimal and expected way. When compiler errors appear, the SWF file will fail to export until the errors are removed.

Runtime errors are generated by ActionScript objects when issues arise after compile time, during playback. Runtime errors come in the form of error events or ActionScript exceptions containing error description objects. Flash Player tries to ignore runtime errors, letting them fail silently in the background, but if a fatal error occurs, it will flood the Output panel with messages and stop the playback of the movie.

Warnings appear at compile time, but generally don't stop the export or playback of the movie.

How to interpret errors and warnings

The first step is to understand the type of visual feedback you'll see in Flash CS4. Errors will present themselves in one of two ways in the Flash CS4 workspace:

• Output panel
• Compiler Errors panel

The Output panel and Compiler Errors panel both appear in the Flash CS4 workspace. I usually group the two panels together and drag them off to the side on a second monitor. My expectation is that I will see compiler errors and my own trace action output consistently as I develop, so I make sure that I put the panels where I can see them without being distracted.

Once you see error feedback in one of these forms, you'll want to make sure to pause and read the related error text. The text may seem cryptic, but there's usually enough of a clue to point you in the right direction. Also, take a moment to observe where you are in the timing of the file. An important part of bug reporting and debugging is being able to define the problem and the steps leading up to it accurately.

Compiler errors

Compiler errors are often easier to deal with than runtime errors as they can be seen clearly during publishing with line numbers pointing to the source of the issue. Compiler errors occur while the ActionScript code is being compiled into the SWF file. This happens when you run the Test Movie or the Publish command (see Figure 1).

Figure 1. A compiler error visible in the Compiler Errors panel in Flash CS4

Please see Compiler Errors in the ActionScript 3 Language and Components Reference for a full list of error types.

Runtime errors

Runtime errors occur while the published SWF file is running in the debug player, the standalone player, or the ActiveX player (see Figure 2). Runtime errors occur commonly as a way to notify you when something isn't right in your application. If you leave these unhandled, the Flash Player tries to allow the script to fail silently, but may pause the playback of the SWF file, causing unpredictable visual results.

Figure 2. A runtime error visible in the Output panel in Flash CS4

Please see Runtime Errors in the ActionScript 3 Language and Components Reference for more information. Also see Basics of error handling in Programming ActionScript 3.0 for Flash for a further breakdown of runtime error concepts.

Warnings

Warnings appear when you publish the SWF as a way of telling you something is breaking a rule in ActionScript, but it's not severe enough to cause an error (see Figure 3). I mostly see warnings for duplicate variable names and migration issues with older content.

Figure 3. A warning message visible in the Output panel in Flash CS4

Please see Compiler Warnings in the ActionScript 3 Language and Components Reference for more information.

Performance issues

While technically unrelated to ActionScript errors and compiler errors, assessing performance and dealing with performance issues is part of the debugging process. This topic affects both designers and programmers even though they may look at it from different perspectives.

Common performance issues include:

• Overloading movie clips in the Flash Player
• Vectors usage and bitmap caching
• Hardware acceleration in Flash Player 9 and 10
• Content loading and caching

The most common way to overload a SWF file is to use too many movie clips or too many overlapping animated vectors. Movie clip efficiency has been improved in ActionScript 3 to allow the use of hundreds of movie clips at any given time, but I find in my own work that overloading vector graphics can force the player to stutter during playback. Usually, the solution comes down to identifying issues with the way graphics are overlapping, the size of the animation on the screen, the level of opacity being used, and proper use of raster optimizations using the BitmapData class in ActionScript or the bitmap caching feature in the Flash CS4 workspace.

Another area I'm seeing performance issues is in using the Flash Player hardware acceleration features with full-screen rendering. Apparently, there are known issues related to the Flash Player's pulling resources from the user's video card configuration. The best option in my own work has been to disable the feature for broad use (at least for now). Tinic Uro has a great blog entry explaining some of these problems. To summarize his relevant points:

• Enabling hardware acceleration often results in slower playback, because content must be specially optimized for a particular GPU for hardware acceleration to work well, and the software rasterizer built into Flash Player often can optimize content that a particular graphics card can't.
• Hardware requirements for acceleration are stiff; your user's machine must be capable of running the latest UIs in the most current operating systems, such as Aero Glass in Windows Vista, in order for Flash to take advantage of its capabilities.
• Pixel fidelity is no longer guaranteed, because your users have different graphics cards, which will all render your content in slightly different ways. Colors can also vary. This includes video.
• Frame rates for your content will max out at the user's screen refresh rate.

One last thing to mention is the issue of content loading and caching. The Flash Player uses garbage collection routines that may cause problems when trying to unload content. For example, if I were to load an Adobe Captivate SWF file into a Loader object in ActionScript, the Adobe Captivate audio would continue to play even after I called the unload method on the Loader object. The solution in this case has been to use the new unloadAndStop API available in the Loader object when viewing the SWF file with Flash Player 10 or later.

Of course, each media type and data routine connecting to external resources has its own challenges and latency issues. Be sure to read the Help documentation related to each type of object you use in ActionScript.

Flash Player bugs

The Flash Player team is constantly trying to improve the features, performance, and security of the Flash Player. From time to time Flash Player bugs and known issues do arise. Your best bet for handling these situations is to develop a process for identifying and documenting bugs so that you can distinguish between problems in your files or larger issues with the Flash Player. Once I've identified an issue, I usually search through the community for related posts. If other people are hitting the issue and seem to be at a dead end, then I start looking for official Adobe tech notes or bug reports.

If you can identify that you're hitting a known issue in the player, usually your best option is to search for a workaround or handle the problem as a documentation issue. In most cases, bugs are worked out as the Flash Player incrementally cycles through its version updates.

Check out the article, Introducing the Flash Player bug and issue management system, for more information on searching for existing bugs and reporting new ones.

Page 2 of 6

Previous Page

Next Page