Optimizing Flash for mobile devices can be tricky business. With AIR for mobile we can take advantage of GPU acceleration on devices, but there’s a lot of confusion about how and when to use GPU acceleration. This test app shows the performance differences with different GPU settings and can be used for benchmark testing across devices.
The app has been published and uploaded to iOS, Android and BlackBerry PlayBook app stores. See this post for more info: http://www.roguish.com/blog/?p=326
* NOTE: This is an ongoing series of tests and optimizations. Please scroll to the bottom to see the latest results and conclusions.
Platform: Google Nexus One
Flash: CS5 (126.96.36.1999)
Publish settings: Render Mode: GPU
Test params: 130 balls, all tests evaluated with UI overlay hidden
Terminology: CAB: cacheAsBitmap, CABM: cacheAsBitmapMatrix
* Note: results are outdated. See updates below.
Mode: Bitmap Display Objects
- CAB: no, CABM: no, rotation: no, alpha fade: no. 23fps, 18ms/frame
- CAB: yes, CABM: yes, rotation: yes, alpha fade: no. 24fps, 18ms/frame (1)
- CAB: yes, CABM: yes, rotation: no, alpha fade: yes. 15fps, 26ms/frame (2)
- CAB: no, CABM: no, rotation: yes, alpha fade: no. 23fps, 19ms/frame (3)
- CAB: yes, CABM: yes, rotation: yes, alpha fade: no. 23fps, 19ms/frame (4)
Mode: Vector Display Objects
- CAB: no, CABM: no, rotation: no, alpha fade: no. 8fps, 31ms/frame
- CAB: yes, CABM: no, rotation: no, alpha fade: no. 23fps, 18ms/frame (5)
- CAB: yes, CABM: yes, rotation: no, alpha fade: no. 24fps, 17ms/frame
- CAB: yes, CABM: yes, rotation: yes, alpha fade: no. 24fps, 18ms/frame (6)
- CAB: yes, CABM: no, rotation: yes, alpha fade: no. 1fps, 18ms/frame (7)
- CAB: yes, CABM: yes, rotation: yes, alpha fade: yes. 14fps, 27ms/frame (8)
- CAB: no, CABM: no, rotation: no, alpha fade: no. 10fps, 34ms/frame
Test Result Notes:
(1) With raster, no difference when adding CAB/CABM
(2) Add alpha fade and performance dips, even with CAB/CABM
(3) Rotation doesn’t degrade performance with bitmaps
(4) Rotation is the same whether using CAB/CABM or not
(5) Major improvement with vectors with just CAB addition
(6) Adding rotation doesn’t impact performance when using CABM
(7) Rotating vector Display Objects without CABM is a lost cause
(8) Adding alpha fading *does* impact performance when using CABM — it’s not supposed to…
UPDATE March 3, 2011
AIR 2.6 for mobile was released recently and stabilized things a bit. Raster and Vector are now more similar, especially when using CAB/CABM. Alpha fading now works as expected with no performance hit for using it while CAB/CABM is enabled. Here’s a chart of the performance with AIR 2.6 on a NexusOne.
* Note: results are outdated. See updates below.
UPDATE March 03, 2011, v.2.0.3
Added StageQuality settings. Anything but LOW setting will cause a performance hit in raster/vector modes.
A bug in the runtime (at-least this is the case on my Nexus One) prohibits the technique of setting the stage.quality to BEST before caching the vector art then setting it back to LOW after the rasters have been created and cached. I have logged the bug with Adobe.
Also, I have noticed that regardless of the stage.quality setting, when using cacheAsBitmap Vector graphics look jaggy. This suggests that setting cacheAsBitmap causes the Vectors to be drawn by the GPU and it doesn’t render with the same quality as CPU rendering.
UPDATE March 06, 2011, v.2.0.4
The latest changes resulted in some significant performance improvements and answered a few burning questions. In short, the latest version achieves 30fps for 130 balls (Raster or Vector mode).
Here’s what’s changed:
- Created a Point object to reference on each ENTER_FRAME of blitting instead of creating a new Point each ENTER_FRAME.
- Discovered that locking ball locations to ints was the reason balls favored the upper-left corner and removed the integer locking. This fix also saved many int calls as a result and may account for some of the performance gain in this version. I may try rounding the value up/down to an int in future versions because placing art on fixed pixel values has always been a recommended best practice in Flash, although mobile devices with high screen resolutions may negate that old advice.
- Converted the FlashBall class to an Object rather than a Sprite, injecting a reference to a Sprite when displaying the ball as a Display Object. This caused significant frame script execution performance gains (now down to ~1-4ms/frame), and is also the likely cause of the framerate performance gains as well.
- Display separate code execution times for physics frame script execution time and full script calculation time.
- Applied velocities when collisions occur rather than waiting until the next frame. This was not a performance optimization, it just seems like that was missing in the original collision code.
- Added option to inline the move and doCollide method calls.
- Added option for opaque backgrounds for Display Objects.
- Added stage.stageWidth = Capabilities.screenResolutionX; per blog post: http://blogs.adobe.com/actionscriptdocs/category/air-releases.
- Show/Hide balls made a single toggle button.
You will need Flash CS5 to work with the app (no Flash Builder requirement).
* Foundation source code for bubble physics from Alexey Gavrilov’s Bubblemark tests: http://bubblemark.com