In this blog entry I will gradually pen any interesting observations that I come across with stage3D which will help actionscript developers gauge a better insight as to what happens behind the scenes.
For the folks who are unaware of stage3d, Stage3D is a new model of rendering developed by Adobe which provides a set of low level GPU accelerated APIs advanced 2D and 3D capabilities across multiple screens and devices (desktop, mobile, and TV) through the runtimes. These APIs provide advanced 2D and 3D developers with the flexibility to leverage GPU hardware acceleration. Please visit http://www.adobe.com/devnet/flashplayer/stage3d.html for more details.
1) Calls synchronous or asynchronous
One question that would perplex stage3d code writers would be as to how do calls stack up. This may assist them in understanding why certain calls take longer than other. Almost all calls in Stage3D are asynchronous. Anything in stage3d is passed as a request to the gpu which gpu then takes up on its leisure and processes them as it feels like. Following are the exceptions and are calls that are synchronous in nature Continue reading…
Within this blog entry I will enlist some of the simple optimizations that one can do within actionscript 3 and particularly iOS mobile applications
1) No modifications to display list within timer events
In case you have a timer event firing at a very high rate and your application is making changes to the display list within this event handler. Consider that the fps of your application is lesser than the rate at which your timer is firing. In such a case you will be making changes to the display list which will never be actually used and you will be making unnecessary calculations within these timer events slowing down the player.
Instead the recommendation in such a case is to use stage.invalidate() call and use the RENDER event. In case you have a very deep display list, do not commit changes directly to the display list instead hold the changes in temporary variable and once you feel that sufficient changes have been made to the display list, then call stage.invalidate(). This will cause a RENDER event to get fired. One should use this event to make changes to the display list from the temporary variables which were holding these changes. Continue reading…