Great news!: Unity will support the Flash platform in future!
Wow that is really an exciting move!

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.

Thibault Imbert from Adobe has published a whitepaper for performance optimization, with a lot of useful information specially targeting Flash Player 10.1 and mobile content.

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.

LocalConnection is a great feature in flash, but unfortunately it has some limitations and the API is somehow “suboptimal”.
Evan Gifford from Blitz has set up an open source project where the size limitations of 40 kb are bypassed and the project provides a nice API.

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

I have commited a bug report to Adobe about the high cpu usage in Flash applications at idle state.

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 😉 ).
(Read more…)

My wishlist for a CSS inspector has had been already fulfilled: http://code.google.com/p/fxspy

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

At my first posts I wrote about my favorite Flex feature: Databinding
Now I will take a look at the opposite, IMHO the most precarious “feature” in Flex: callLater()

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:
(Read more…)