FLASH8 player model: Flexible runway

Since FutureSplash, has been engaged in the work of Flash, for Flash ' "> Player development, I also have their own views.

Welcome to the discussion of this flexible runway model.

I view the Flash player as a runway. There are two distinct parts on the runway, one for ActionScript (which includes event handling) and one for the content to be displayed on the screen. At run time, the Flash player moves around the runway according to the frame speed specified in the SWF file. The player attempts to play the file at a predetermined speed, regardless of the instructions given to the player. The specified frame speed is the maximum speed of the runway, and playback speed can only be below this limit.
Player Runway model

The SWF file tells the player to do the appropriate thing at the specified time. The runway is stretched when the player handles ActionScript or displays instructions to the screen or both. If you have a lot of data or movie clips to deal with, or if you're dealing with all the content or instructions you add to a single link in the runway, the player skips the instructions that are required to execute it and completes a loop in the shortest possible time, but not faster than the specified frame speed.

When ActionScript is heavy

When the graphics are heavy

When both ActionScript and graphics are heavy

There are several other aspects of mixing this model. First, the player constructs the graphic elements into a descending directory tree. Starting with a basic node, there are a number of branches consisting of frame content and subordinate nodes. Every element of the player's looping tree directory is processed. In the current Flash 7 player, the contents of the frame are scanned and processed as needed from the level0 to the highest level in a small to large order. The key to the graphical presentation is to make the hierarchy of the tree as simple and distinct as the intrinsic needs of the element. The fewer menus The tree has, the lighter the level of the graphic elements will appear on the screen more quickly.

The structure of the tree also applies to the processing of ActionScript bytecode. In the as phase, the status of the tree will be scanned in byte code form. Each specified event will be processed progressively. ActionScript is based on stacks, so that all byte code is lumped onto the stack and processed linearly according to the tree's structure. The as part of the runway will be expanded according to the amount of code and events on the given frame. Although there is no fixed method for delaying the execution of code, the player will handle all the content that is requested for processing in each frame loop. Interestingly, we noticed that the code that uses functions and events can be arranged into a sequence that waits to be processed. In a sense, the player never consumes faster, it will always do all the work you require, will not submit to a frame of the loop. The key is not to require the player to handle too much content on the given frame, and to handle the latest frames logically and with events.

As for Flash 8, from the appearance of the beta version of the player, Cacheasbitma allows the graphic to be stored as a bitmap as a branch of the MC. The vector map is stored as a bitmap, but will not be rendered until the picture changes. A good way to allow the player to be centrally stored in different areas of the player is to focus on how vector storage is exploited. In a tree-based representation model, some branches of the tree are set to Branch.cacheasbitmap=true, and the storage process creates a bitmap on the first level and will reuse the bitmap until the vector map of the region is marked as dirty. Similarly, if each frame bitmap storage branch is marked as dirty, you have to force the player to produce a bitmap (processing + storage) in each frame loop. In my tests, optimizing the use of Cacheasbitmap is not as simple as it seems.

In short, the Flash8 player clearly shows that it is a combination of two different elements, graphics processing and ActionScript bytecode processing. If you abuse one or both of the player's operating efficiency will be reduced, resulting in the next cycle before the conclusion that everything has been completed. In larger project development, the Flex track helps us explain some of the arcane logic behind the good performance optimizations shown in flex and Flash development. As many times as I have said before, "wait for that frame."