I have had recently a look to Unity in search for alternatives to Flash, and was wondering why they are not supporting the Flash Player. They already supports a lot of different platforms, but Flash was missing. I thought the technical limitations and differences would be a too hard barrier.

But now they released the news that they are working on the support for exporting Unity projects to the Flash platform as well as to Android, IPhone (and the rest of the I… derivates), XBox, Mac/PC desktop apps and their Unity Web Player (Linux Player is in development). It is becoming a real tough multi-platform tool! This could have a deep impact, as Unity seems from technological point of view much more advanced then Flash and the main barrier for using it in the web, was the low player penetration of the Unity Web Player. So it was locked to the special cases where the installation of a new plugin is no problem for users, but unfortunately for 90% of the mainstream clients and projects this is a no go. But with this strategy they will get in one move the support of the 99% penetration of the flash player (ok, with the latest player version that is not correct, but people don´t care so much about an update of the Flash Player then about a new installation of an unknown plugin).
And Adobe is getting a real strong competitor, so hopefully they are forced to pay more attention to performance and development environment. The current Flashbuilder is compared to the tools available for Java or .NET not very competitive, to express it friendly. I have not worked with Unity yet, but will use the next opportunity to try it out.

I am also wondering how much they can cover outside the classical 3D world? Flash has started as a pure animation tool and has become a main player for web application development. I bet the inventors didn´t expect this. So why should not Unity become a tool also for classical applications, 3D comes free if needed, and it seems that 3D will become more and more an intrinsic part of up to date software. 3D-TV sets and Mobiles are currently the hot thing and I think it´s only a question of (hopefully not too much) time, until 3D displays are common also at desktops. 3D content will be the missing link then.

Unity is just ready to take off!

Looking forward also to the new Flash Player (Molehill) which brings GPU-accelerated 3D to the Flash platform.

Some parts sounds somehow strange, like the recommendation to avoid Event Dispatching as for every event an object has to be created. On the other hand they recommend object pooling for reusing objects. So the question pops up, why the native Event Dispatching is not implemented in the way that it benefits from a native object pooling? When performance optimization is leading to bad coding practice, something in the  technology seems to be wrong. The poor method execution performance in Flash is one of these issues.

Here just a few random issues discussed in the paper:

– Setting not used objects explicitely to null helps the garbage collector

– Call dispose() on the BitmapData object when not used anymore

– When using Filters 2 Bitmaps are created and kept in memory. Applying a filter is CPU intense, so try to use pre-rendered Bitmaps instead.

– Deactivate interactive objects when no Mouse interaction is needed (mouseEnabled, mouseChildren)

All in all it is good to see that Adobe is aware of the performance problems and hopefully will push the Flash Player forward using the optimization headroom available at the compiler level and the Flash Player itself. Maybe the current effort to make Flash “ready for mobile” will give us the same performance boost like with AS3 that was primarily introduced because of the greed of Flex which simply didn´t perform on the AVM1.

Resources:
http://labs.blitzagency.com/?p=650
http://code.google.com/p/flashlcs/
http://rockonflash.wordpress.com/2009/03/05/new-localconnection-api-rocks-and-its-os/
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/LocalConnection.html

Please vote for this bug, so it has higher chances to get fixed soon.

There is also another bug report by Grant Skinner regarding the same issue.

Here is a copy of the bug report (if you are too lazy to register @ Adobe ).

Steps to reproduce:
1. create a hight number (>1000) of displayobjects and add them to the stage (visible area)
2. set the framerate to a hight value (>50)
3. move the mouse over the stage and don´t move it (idle state)

Actual Results:
idle cpu usage (taskmanager) is quite high (>10%) depending on the framerate, cpu and number of displayobjects

Expected Results:
in idle state there should be nearly no cpu consumption (in AS2 -> AVM1 it was quite low)

Workaround (if any):
reduce the framerate, set mouseEnable and mouseChildren to false whenever possible

Here is a detailed discription and testresults:

Problem:
We are working on a huge flex application (170 000 lines of code) and run into some performance problems.
We have set the framerate to 60 fps and the cpu consumption of the application was about 20% on a 3Ghz quadcore machine. there were no user interactivity and rendering going on.
So we investigated the problem.
After setting the framerate to 25 fps and setting the mouseEnable and mouseChildren property to false at the displayObjects where we don´t need mouse interactivity, we got an acceptable cpu consumption in the idle state. I am still wondering for the reasons for this behavior and specially for the different behavior in comparison to the old virtual machine (AS2). A strange observation was also that when moving the mouse over a textField the cpu consumption goes down to 0%.

Test situation:
I Create 2000 displayObjects and add them on the stage (visible area). I give the flashplayer (standalone flashplayer 10.0.r12, release version) the focus and put the mouse over the playerwindow. I don´t move the mouse and there is no rendering going on. The cpu consumption is quite high depending on the framerate.
The same test scenario with AS2 (AVM1) does not show such a high cpu consumption.

When I set mouseChildren at the stage to false the cpu consumtion goes down to 0%. Setting the mouseEnabled property at every Sprite to false has just a small effect on reducing cpu consumption. I tried it also with a container sprite in which all the 2000 sprites where added, setting the containers mouseChildren to false also reduced the cpu consumption radically. The same when I set mouseEnabled of the container AND of all Sprites to false but don´t set mouseChildren of the container to false. Setting mouseEnabled of all Sprites to false but not at the container has only a small effect. Seems like the flashplayer recognize if no children has mouseEnabled set to true and then don´t need to traverse throught the displaylist.
For me it seems that the flashplayer has to check every frame for the mouseEnable properties and this consumes resources. If mouseChildren is set to false it has not to go further up the displaylist, so this is much faster.
Regarding the TextField: As long a the selected property is set tot true it reduces cpu consumption down to 0%. It seems that when moving the mouse over a selectable textField that the flashplayer don´t has to check any other displayObjects for mouse interactivity.

In the flex profiler I have seen an high growth of the consumed time by [reap] (98%) and Timer.tick (1%). ([reap] is an internal process: Flash Player reclaims DRC (deferred reference counting) objects.)

I am wondering which changes in the AVM2 has causes these problems and if there are options for optimizations. I am also wondering why there is no event based (like os interrupts) model possible, it seem that the flashplayer has to check every frame for possible os input (mouse move,…).
I am also wondering if the strategy I have seen in the flex frameworks core classes to set the framerate up to 1000 fps for speeding up rendering and then reset it to the original framerate, could has negative side effects due these behavior.
Could it be that it is related to the native support for the mouseWheel event passed from the os to the flashplayer? Because this was a change from the old virtual machine, where the mouseWheel where not passed to the player.

Test results:
AS3 code (-> AVM2)
AS3: framerate 24:
mouse over the stage: 3%
mouse over the textField: 0%
mouse over the one sprite: 3%
mouse over the stack of 1000 sprites: 3%
AS3: framerate 120:
mouse over the stage: 9-14%
mouse over the textField: 0%
mouse over the one sprite: 10-13%
mouse over the stack of 1000 sprites: 14-18%
AS3: framerate 1000:
mouse over the stage: 36-40%
mouse over the textField: 0%
mouse over the one sprite: 22-40%
mouse over the stack of 1000 sprites: 17-33%

AS2 code (-> AVM1)
AS2: framerate 24:
mouse over the stage: 0%
mouse over the textField: 0%
mouse over the one sprite: 0%
mouse over the stack of 1000 sprites: 0%
AS2: framerate 120:
mouse over the stage: 6%
mouse over the textField: 0%
mouse over the one sprite: 6%
mouse over the stack of 1000 sprites: 6%
AS2: framerate 1000:
mouse over the stage: 8%
mouse over the textField: 0%
mouse over the one sprite: 8%
mouse over the stack of 1000 sprites: 8%

Environment:
Flashplayer 10.0.r12 (release version)
OS: Win XP pro SP2
3Ghz Singlecore
2 GB Ram

AS3 code:
stage.frameRate = 1000;
for(var i:uint = 0; i < 2000; i++)
{
addChild(getSprite());
}

var tf:TextField = new TextField();
tf.x = 120;
tf.width = tf.height = 100;
tf.text = “test”;
addChild(tf);

var s:Sprite = getSprite(0xFF0000);
s.x = s.y = 120;
addChild(s);

function getSprite(col:uint = 0x00FF00):Sprite
{
var sprite:Sprite = new Sprite();
with(sprite.graphics)
{
beginFill(col);
drawRect(0, 0, 100, 100);
endFill();
}
return sprite;
}

AS2 code:
this.frameRate = 1000;
var i:Number;
for(i = 0; i < 2000; i++)
{
attachMovie(“mc”, “mc”+i, i);
}

this.createTextField (“tf”, ++i, 120, 0, 100, 100);
tf.text = “test”;

i++;
var mc:MovieClip = attachMovie(“mc”, “mc”+i, i);;
mc._x = mc._y = 120;

source file:
http://bugs.adobe.com/jira/secure/attachment/27527/idleCpuTest.zip

A great code formatter as Eclipse plugin for Flex Builder: http://code.google.com/p/flexformatter
Download: http://sourceforge.net/projects/flexformatter/

HP has published a security analysis tool for Flash content. It´s also a decompiler to inspect the Actionscript code: SWFScan

Good overview about security issues in Flash:
http://www.owasp.org/index.php/Category:OWASP_Flash_Security_Project
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html

A great resource for open source flash/flex tools and projects: http://www.flashchemist.com/104-free-opensource-apis-libraries-and-tools-for-the-flash-platform.html

If you have a dodgy problem that a certain property is not available when it already should be and you ask someone at flexcoders you often get the advice, “try callLater” for a quick work-around. Sometimes this helps, but it leaves a bad smell, because often it´s just hiding some other problems in the code.
So when we worked on a large-scale Flex application we have used it sometimes in the beginning, but after a while we decided to avoid callLater. To find and solve the real problem is simply the better solution – and we never needed it again – there was always another solution to solve a particular problem (maybe we just have had luck).

Unpleasantly we get confronted with the fact that callLater is used inside the Framework at the heart of the layout engine.
We struggled with some strange problems. For instance we got a NullPointer exception in the updateDisplayList method of a custom component, which has already been cleaned up properly and removed from the displayList. It turned out that the layout mechanism delayed with callLater an invocation of updateDisplayList but our stuff there has already been removed and threw an exception.
It was not hard to fix, but it demonstrated us that some asynchronous stuff was going on behind the scenes which was out of our direct control.

So for me callLater leaves always a certain bad smell.

Unfortunately I never found time to really investigate how it´s implemented and what are the concepts behind it.
So it was time to catch up with this issue:
CallLater is basically a method in UIComponent which delays a passed function to the next EnterFrame OR Render event.
Often in den docs it´s just described that it will delay to the next frame, which is not correct because it could be that your function is executed already at the Render Event, which happens in the same frame and is the last opportunity where User code can be executed before the screen is rendered.

For more details about the internal concept of a frame in Flash and the relevant events see the great article by Sean Christmann:

Here is a good illustration from his article about the anatomy of a frame in Flash:

All functions passed to callLater are queued up in an array and are executed at the EnterFrame event or Render event. It is possible that the executed function has some other callLater invocations again, so the final execution sequence could be delayed over several frames.

CallLater is used inside the Flex Framework in several classes. The main use case is probably inside the LayoutManager.
There is a concept called phased instantiation which means basically that at application start-up the 3 phases in the UIComponents life-cycle (validate properties, validate size and validate displayList) are not executed in one pass, but are delayed with callLater to 3 half-frames. Half-frame because the Render event happens in the same frame as the EnterFrame event.
This should reduce performance peaks at application-startup and should increase the UIs responsiveness.
You can also use it later on in your application if you have to render heavy stuff, to balance the load across frames.

So far so good. But…
First let me emphasis that I am sure that the SDK architects has had some good reasons for implementing callLater, but it introduces an asynchronism which could be hard to control. Normally with async stuff you have an event driven approach, so you get informed when the async task is done.
With callLater it´s not so clear when the last callLater is really finished. There is an UpdateComplete event in UIComponent and LayoutManager which helps to get informed when the last callLater is executed, but in-between, you don´t have control about the distinct moments of your function calls.

Another issue is that you cannot control if your heavy load is really spread over 2 frames. It could be that it is just executed inside one frame at the EnterFrame event and at the Render event, so it could be that you don´t win anything from the load-balancing perspective.

Performance-wise there could also be perceptible delays caused by repeatedly callLater executions.

I guess there are many special situations in the framework code (probably mostly measurement stuff) which are difficult to handle, but i guess it should be possible (maybe I am too optimistic?).

There seems to be a problem to get the correct measurement when you set a new text in a TextField before the frame is actually rendered (see this post at flexcoders), but if this is an unsolvable problem then it should be urgently fixed in the Flash Player.

References@livedocs:
callLater()
usePhasedInstantiation