Entrepreneur, father, and interactive software developer.

Monthly Archives: March 2010

I would like to see Flash Player support an expanded rendering API. Today Flash has a very limited rendering API and constantly renders any object added to the DisplayList (exceptions for cacheAsBitmap & MouseEvent.updateAfterEvent). Due to the nature of constant rendering, the player is required to constantly switch from rendering graphics to executing logic (AVM bytecode) as highlighted by the Elastic Racetrack.

Having the player constantly render is expensive and if developers could control the rendering cycle, we would see a new class of higher performance graphical applications and games using Flash Player and AIR.

QUESTION: What if developers could have programmatic control of rendering?

flash.display.Stage.frameRate = 0;//turn off rendering

this.mySprite.render(); //render a single sprite and its children

Today we do have access to a rendering API within flash.events.MouseEvent.updateAfterEvent() and cacheAsBitmap but these are of limited use for those wanting fine grained control of the renderer. The assumption remains that player is constantly rendering but you can skip rendering some objects or on mouse events force rendering to update graphics quickly. The assumption is that the entire displayList is rendered (except where cacheAsBitmap is true) vs designating certain objects in the displayList tree for rendering.

PROPOSAL #1: Rendering is turned off when stage.frameRate is set to 0.

flash.system.System.renderMode = flash.display.RenderMode.ONDEMAND; //no rendering but you get enterframe events

I know this would be a powerful API in the hands of game and application developers and would allow a developer to turn off rendering once an animation completed. Obviously it isn’t perfect but then again what is? I would love to hear your thoughts on adding a rendering API into Flash Player.

The proposal has been submitted as a feature enhancement using the public process. Once filed feature enhancement are routed to the Flash Player Product Managers for review. If you have features you want to see, feel free to submit them here.

Assuming you used the exact name of the generated MXML file, you project is 100% ready to run, debug, and profile. Within the MXMLC compiler, MXML files are translated into ActionScript classes just before compilation and if you use the same base name, they are interchangeable.

So why use ActionScript Only AIR projects? Mobile.

I have been using this workflow since pre-MAX for mobile application development. It works seamlessly with AIR on mobile.

Tinic Uro of the Adobe Flash Player engineering team knows way to much about time. Tinic posted on some internal changes to Flash Player 10.1 Beta 3 and is the first to talk publicly about the timing model updates. These changes are very significant for Flash and Flex developers and designers as they impact how content runs cross-browser, cross-platform, and cross-device.

Changes:

New Timer – Flash Player 10.1 beta 3 introduces its own periodic timer that delivers consistent cross platform behavior and eliminates the dependency on different browser timer implementations.

Less Polling – The timing model change decouples the SWF frame rate from, for example, the video playback frame rate inside the SWF and eliminates having the Flash Player poll up to 120 times a second even if nothing is happening.

Throttling – Non-visible SWFs and SWFs on hidden tabs are throttled down to 2 frames per second. No rendering occurs unless the SWF becomes visible again. Timers and local connections are also clocked down to 2 FPS. Video is decoded but not rendered or displayed using idle CPU time while audio plays back at 8 FPS to preserve backwards compatibility.

Synchronized – Frame rates of visible SWFs, timers and local connections are limited and aligned to the player’s periodic timer. Video can play back at any frame rate, increasing video playback fidelity.