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…)