Monthly Archives: March 2010

Feature Request: Rendering API (FP-4218)


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.

BENEFITS:
- Turn off constant rendering
- Developer must designate items to render via the method below.


PROPOSAL #2:
flash.display.DisplayObject.render():void

BENEFITS:
- Render a sprite and any child objects ondemand
- Pre-render DisplayObjects not attached to the DisplayList
- Render only part of the displayList tree. MySprite.render vs stage.render()


The other way to go is to have modes for the renderer like so:

flash.system.System.renderMode = flash.display.RenderMode.CONSTANT;
//todays default behavior

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.

FEATURE REQUEST FP-4218

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.

Cheers,

Ted :)

Configuring ActionScript-Only AIR projects with Flash Builder 4


There is a trick to setting up an AIR Application using ActionScript-only within Flash Builder 4. Here is how to do it:

1. File > New > “Flex Project”
2. Choose a Project Name: “Foo”
3. Select “Desktop (runs in Adobe AIR)”
4. Press “Finish”
5. Delete “Foo.mxml”
6. File > New > ActionScript Class named “Foo” with “flash.display.Sprite” as SuperClass

7. Press Finish.
8. Right Click on “Foo.as” and press “Set as Default Application”
9. In Foo.as, add this line in the constructor:
“this.stage.nativeWindow.visible = true;”
10. Run & Done!

Here is a sample “Foo” Project for Flash Builder 4: Download

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.

Cheers,

Ted :)

Jiffiness – Flash Player 10.1 gets a new clock!


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.

Benefits:

  • Significantly lower CPU utilization with non-visible SWF content
  • Extended battery life
  • Consistent, cross-platform timer behavior improves application performance consistency for developers
  • Improved audio/video synchronization and video playback fidelity
  • Backwards compatible – audio and video continue to play in hidden tabs
It is a great change for Flash Player 10.1. Regardless of which browser or operating systems or device you use, we will see Flash content playback more consistent and performant across screens.
Cheers,
Ted :)