http://www.cmcmarkets.co.uk

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.

Lets assume that we have a css file with type selectors and class selectors, a module based application and some custom components which are designed the way that you can use them out of the box and that they can be individually skinned and styled by other developers reusing them. That´s what custom components are for, right?

So the first question is:
How are the styles compiled into your swf file?
Assume that they are defined in an external css file. You know you can compile css files to swf files and load them at runtime or simply compile them into your application at compile time with a simple assignment like this:

Here is the content of our simple css:

Button
{
        color: #990000;
}
.myCustomStyle1
{
        color: #009900;
}
 /*
     some additional styles here...
     like Button.myCustomStyle2
*/

That´s what we will use for our example here.

In this case the MXML compiler creates a bunch of classes and inserts the css definitions right into a method called from the constructor in the generated Applications class.

public function StyleExample() {
        mx_internal::_StyleExample_StylesInit();
}
mx_internal function _StyleExample_StylesInit():void {
        var style:CSSStyleDeclaration;
        // Button
        style = StyleManager.getStyleDeclaration("Button");
        if (!style) {
                style = new CSSStyleDeclaration();
                StyleManager.setStyleDeclaration("Button", style, false);
        }
        if (style.factory == null) {
                style.factory = function():void {
                        this.color = 0x990000;
                };
        }
        // myCustomStyle1
        style = StyleManager.getStyleDeclaration(".myCustomStyle1");
        if (!style)
        {
                style = new CSSStyleDeclaration();
                StyleManager.setStyleDeclaration(".myCustomStyle1",
                                           style, false);
        }
        if (style.factory == null)
        {
                style.factory = function():void
                {
                        this.color = 0x009900;
                };
        }
        // similar code follows here....
}

I only pasted the relevant code, so this is not complete but should give the basic idea.
So what happens here?

A CSSStyleDeclaration is created for the given stylename or class if it´s not already existing in the StyleManager (at a modular application some other application could have already created this style). Then the definitions from the css file (here the color property) are added to the factory function.
It is interesting that the class selectors and type selectors are treated the same way regarding storing the style object in the StyleManager. It is simply the selector name which is used as the key in the _selectors Object (hashtable). Only the “.” in the selector name is the visible difference.

public function setStyleDeclaration(
                                selector:String,
                                styleDeclaration:CSSStyleDeclaration,
                                update:Boolean):void
    {
        styleDeclaration.selectorRefCount++;

        _selectors[selector] = styleDeclaration;

        // Flush cache and start over.
        typeSelectorCache = {};

        if (update)
            styleDeclarationsChanged();
    }

The CSSStyleDeclaration has also a defaultFactory which is used if there is no factory defined (no css file). Additionally there is an overrides Object which is used to store styles set at runtime vial setStyle(), but this will not be further considered yet.
This leads us to the next part:
How should a default style be applied to a custom component?

How Flex is handling this? The MXML compiler generates a bunch of style classes:
For instance a style class for the Button:

public class _ButtonStyle
{
    public static function init(fbs:IFlexModuleFactory):void
    {
        var style:CSSStyleDeclaration =
                         StyleManager.getStyleDeclaration("Button");
        if (!style)
        {
            style = new CSSStyleDeclaration();
            StyleManager.setStyleDeclaration("Button", style, false);
        }
        if (style.defaultFactory == null)
        {
            style.defaultFactory = function():void
            {
                this.fontWeight = "bold";
                this.paddingTop = 2;
                this.cornerRadius = 4;
                this.textAlign = "center";
                this.verticalGap = 2;
                this.horizontalGap = 2;
                this.skin = mx.skins.halo.ButtonSkin;
                this.paddingLeft = 10;
                this.paddingBottom = 2;
                this.paddingRight = 10;
            };
        }
    }
}

This class is added to the mixins array at the generated _StyleExample_mx_managers_SystemManager class.
The mixins are a strategy to get injected some code at application startup before anything else is instantiated. It calls the static init method, so it is executed before the actual classes constructor is called.
A similar strategy with a static initializer is used in some classes in the datavisualisation package to pack some default styles into a component, so that there is no dependency that there are some styles assigned to the component from outside.
That´s seems to be a pretty nice way to setup the default style a component needs. If the user of the component wants to set some different styles, it can be applied easily via css, styles set in mxml or at runtime via setStyle (if possible, this should be done in the preInitialize phase to avoid performance penalties).

One thing which should be considered when using styles (specially in a large application with modules) is the fact that the style declarations are stored with the selector name as key in an Object (hashtable). So if 2 developers are using the same selector name they end up with a conflict that the later instantiated module will use the already created style and not the one which was compiled to the module.
The same applies if you use the same stylename inside one application, the first one used wins.
To get rid of this problem a kind of namespace strategy can be used ([modulename] + “stylename”). Unfortunately the Flex framework does not give any support for this problem.
Tell me if you know a more elegant solution!

LangDetecten>de YahooC

MXML

It´s important to activate apples firmeware password protection to ensure that a harddrive reformatting or replacement will not allow booting up your mac without password.

An alternative firewall for mac to control outgoing connections from your apps and services is little snitch. Unfortunately apples built in firewall only allows control for incoming traffic.

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 = 0×00FF00):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

If you feel this would be a nice feature, vote for it on the Adobe Bugbase.

You probably have seen already the Flex Style Explorer. It gives a good overview of the different styles of the standard Flex components.

BTW: Did you know that parts of Flex Builder are open source (the derived stuff from Eclipse)? You can download it at Adobe.

When you compile a Flex application the compiler runs the compilation in 2 steps:

• The mxmlc compiler generates a lot of Actionscript classes
• The compc compiler compiles from the generated classes plus your custom classes the swf file

These 2 steps are normally not visible, because the generated code is not stored in your project. If you add the compiler argument -keep (or -keep-generated-actionscript=true) in your compiler settings in Flex Builder, you will see a generated folder inside the src folder containing a lot of Actionscript files.

There are different kinds of files generated:

• Classes defining the default style for Flex components
• Classes holding the Resourcebundle properties
• Classes for embedded skins
• Classes for Flex Application setup
• Classes for Flex DataBinding

The style, skin and property files are out of our scope here and has no direct relation to this topic.
The classes which are used for setting up a Flex Application are our entry point, but will not be discussed in detail (even it would be very interesting to have a closer look to Mixins, [Frame] metadata tags and all these exotic stuff…).

So lets look at our relevant classes for DataBinding (all others has been removed):

The entry-point of our Flex application is _DBGC_mx_managers_SystemManager.
This class extends SystemManager. The SystemManager is the main class and the first DisplayObject added to the stage. It does a lot of setup stuff.
At the first frame in our MovieClip the preloading is handled. At the second frame the Application (DBGC) is instantiated. In the static info() method the mixins classes are defined. At frame 2 the mixin classes are inited via the static method call init().

The DBCG class (file: DBCG-generated.as) is our Application class.
Here the MXML components are converted to UIComponentDescriptors which handles the instantiation of these Components.
At initialize() an array of Binding objects are created.
The Binding class use anonymous functions for resolving the source and destination properties.

var binding:Binding = new mx.binding.Binding(this,
    function():String
    {
        var result:* = (bindableVO.myBindableProp);
        var stringResult:String = (result == undefined ? null : String(result));
        return stringResult;
    },
    function(_sourceFunctionReturnValue:String):void
    {

        myLabel.text = _sourceFunctionReturnValue;
    },
    "myLabel.text");

The _DBGCWatcherSetupUtil creates an array of PropertyWatcher objects, setup the relationship for chains and pass the Binding object to the PropertyWatcher.

watchers[0] = new mx.binding.PropertyWatcher("bindableVO",
    { propertyChange: true },[ bindings[0] ], propertyGetter);
watchers[1] = new mx.binding.PropertyWatcher("myBindableProp",
    { propertyChange: true },[ bindings[0] ], null);
watchers[0].updateParent(target);
watchers[0].addChild(watchers[1]);

After the basic setup execute() is called on every Binding object.
Here is the complete code:

override public function initialize():void
{
        mx_internal::setDocumentDescriptor(_documentDescriptor_);

        var bindings:Array = _DBGC_bindingsSetup();
        var watchers:Array = [];

        var target:DBGC = this;

        if (_watcherSetupUtil == null)
        {
                var watcherSetupUtilClass:Object = getDefinitionByName("_DBGCWatcherSetupUtil");
                watcherSetupUtilClass["init"](null);
        }

        _watcherSetupUtil.setup(this,
                                function(propertyName:String):* {
                                     return target[propertyName];
                                },
                                bindings,
                                watchers);

        for (var i:uint = 0; i < bindings.length; i++)
        {
                Binding(bindings[i]).execute();
        }

        mx_internal::_bindings = mx_internal::_bindings.concat(bindings);
        mx_internal::_watchers = mx_internal::_watchers.concat(watchers);

        super.initialize();
}

private function _DBGC_bindingsSetup():Array
{
    var result:Array = [];
    var binding:Binding;

    binding = new mx.binding.Binding(this,
        function():String
        {
            var result:* = (bindableVO.myBindableProp);
            var stringResult:String = (result == undefined ? null : String(result));
            return stringResult;
        },
        function(_sourceFunctionReturnValue:String):void
        {

            myLabel.text = _sourceFunctionReturnValue;
        },
        "myLabel.text");
    result[0] = binding;

    return result;
}

So lets jump into the Binding Class. This is a regular Framework class.
The execute() method is basically applying the source value to the destination. In-between there is a lot of error handling going on, but basically it´s nothing else as reading out a value and setting it to the destination. No event dispatching is included until now.

The setting of the value happens on start-up. If the bindable property changes later, event dispatching comes in.
This happens in the PropertyWatcher class:
An event handler is added at the source object and the PropertyWatcher is listening for the defined event type. It is invoked with weak reference, so the fact that MXML Bindings cannot be removed will not lead to memory leaks.
The event handler checks if the dispatched PropertyChangeEvent contains the same property name as our PropertyWatcher represents and calls notifyListeners() if the property name matches.
On every Binding object which is registered as listener watcherFired() is called.
And here again the execute() method is responsible for passing the value from the source over to the destination.

The last missing link is the class which dispatch the PropertyChangeEvent.
The BindableProperty (file: _BindablePropertyVO-binding-generated.as) is the place where this happens.

[Bindable(event="propertyChange")]
public function get myBindableProp():String
{
    return this._834029286myBindableProp;
}

public function set myBindableProp(value:String):void
{
    var oldValue:Object = this._834029286myBindableProp;
    if (oldValue !== value)
    {
        this._834029286myBindableProp = value;
        this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent(this,
                                  "myBindableProp", oldValue, value));
    }
}

Here the gettter/setters are created for our [Bindable] property. The compiler defines “propertyChange” as event type - [Bindable(event="propertyChange")] and dispatches a PropertyChangeEvent if the value has changed.
If the class containing the bindable property is not a subclass of EventDispatcher the compiler set the classes interface of BindableProperty to IEventDispatcher, adds the methods of IEventDispatcher and uses an instance of EventDispatcher via composition.

Note that this code is only generated when you don´t use custom events in the [Bindable] metadata tag ([Bindable(event="myCustonEvent")]).

I don´t know how this class is linked into the Application, it has no reference anywhere. I guess the compiler do this job behind the scenes, as well as with the interface classes and some other stuff.

Lets have a look to the moments when DataBinding is executed:

At Application start-up the Binding is executed for the first time.
Here is the call stack (Breakpoint at Binding.execute():

Due the fact that the component is not created yet, the Binding fails in a catch Block at wrapFunctionCall() in the Binding class. The catch block is pretty slow, i am wondering why this initial execute() is not prevented? At least the try/catch could be replaced with a check against null which is much faster then falling into the catch block. I guess in large applications this could noticeable slow down start-up time.

At the time the component is added to the Application executeBinding() is called and triggers the second execute().

At this point the component is valid but there is only the value passed which is defined in the property declaration. This value is often not set at this momens so it is null.

If you setup your initial value at the initialize event a third run will be triggered:

You can prevent this if you set the value right at the variable declaration (if possible) and so prevent to trigger DataBindings third round.

Conclusion
Finally we are through the basic parts how DataBinding is working behind the scenes. To go further it´s best to step through the generated code and try out different scenarios.
We only have had a look into Binding in MXML. If you use BindingUtils just the code for event dispatching from the [Bindable] metadata tag is created.

The generated code for DataBinding with MXML do a lot of error handling. it´s clear that it has some performance drawbacks but gives the benefit that it is very fault-tolerant. You also should consider that there are a lot of different features and use cases for Binding (functions, expressions, 2-way Bindings,…) which has to be handled.

For large applications BindingUtils are the better choice and prevents several performance drawbacks, specially at start-up time.