flash EventDispatcher and Event

[Kessler CTR Mark J <ma...@usmc.mil>]

    Ok I've spent a little bit of time looking into both the flash EventDispatcher and Event.   To get a good picture of how they interact and target the DisplayObjects.  They have quite a few missing properties and communicate without using public methods.

    Turns out they just execute code inside the player itself natively [1].  So my observations show the missing properties/methods are actually controlled in the player which explains a few things.  Giving a small example from the flash.events.Event.


    When using the preventDefault on an event and be able to check if it's prevented...

public native function preventDefault():void;
public native function isDefaultPrevented():Boolean;


    However simple things like being able to see if propogation has been stopped, are not present but still being used internally to the player...

public native function stopPropagation():void;
or
public native function stopImmediatePropagation():void;


    Since the method dispatching the events is in the player and has access to the properties that aren't in the event or eventdispatcher.

private native function dispatchEventFunction(event:Event):Boolean;


    What this means is your two choices for coming up with a more controllable EventDispatcher.

A.  Override the EventDispatcher  methods and run a parallel set of methods and properties while still calling  the existing EventDispatcher parent (super).  It works well, but seems inefficient to be doing everything twice (overridden and super both doing looping operations).  Less inefficient if using a Dictionary or Map to store the event handlers.

B.  Create a new FlexEventDispatcher / IFlexEventDispatcher and modify something like the Flex Events and FlexSprite to work with the new dispatcher.    Which seems like an uphill battle to do lots of little overrides on the existing base components we have access to.  It would only have a functional benefit if a set of components would start using it as part of its base.


    Looks like Adobe has a tight grasp on this.   Anything else will always be a work around.  The only long term way around this type of stuff would be to change all the base components and start a new component namespace that starts using a base of all Apache Flex made classes (no small task in itself).


[1] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/statements.html#native


-Mark

RE: flash EventDispatcher and Event

["Michael A. Labriola" <la...@digitalprimates.net>]

>the problem lies with how Adobe implemented it.  They basically left method prototypes in the AS and execute all of it in the player.  

Mark,

That is generally how these specs are implemented. Event dispatching is a feature of the virtual machine that is Flash Player, it's not a framework level concept. The same is true in browsers, etc. Any feature of the virtual machine is implemented in native code with only an ActionScript definition to link against.

The native code in the player executes the event logic much, much faster than the ActionScript equivalent. It's been a long time, but somewhere around early Player 9 we did a simple test to see what this movement to native code actually bought us and I believe the results were a staggering 25-30 times faster than could be implemented in AS.

Considering the gobs of events Flex dispatches, that change is _part_ of what made Flex 2 viable from a performance standpoint over the Flex 1.x versions.

Mike

RE: flash EventDispatcher and Event

[Kessler CTR Mark J <ma...@usmc.mil>]

Well it did start with the issue FLEX-33608 [1].  They wanted to be able to remove all event listeners.  I had an old piece of code that created one time use listeners so I was able to toss together a work around for them.

But I went down the road of seeing what was feasible for being able to add simple functionality to the EventDispatcher anyways.   The W3C DOM event  Specification is understandable, but the problem lies with how Adobe implemented it.  They basically left method prototypes in the AS and execute all of it in the player.  

Starling has this [2].  They've created their own event dispatcher to be able to gain control of this.

[1] https://issues.apache.org/jira/browse/FLEX-33608
[2] http://doc.starling-framework.org/core/starling/events/EventDispatcher.html

-Mark

-----Original Message-----
From: Alex Harui [mailto:aharui@adobe.com] 
Sent: Thursday, July 25, 2013 1:27 PM
To: dev@flex.apache.org
Subject: Re: flash EventDispatcher and Event

Hi Mark,

I'm a bit lost on the context here.  The Flash Player is more or less
implementing the W3C DOM Event Specification.  Are you looking to enhance
it?  If so, why?  A whole group of people over at W3C decided this API set
was sufficient.  Or did I miss where they are also updating the
specification?

If this is related to the attempt to know who is listening for events on
an object, keep in mind that I've seen folks want to know that in order to
get all of those listeners to call removeEventListener, but I've never
really understood why, since those listeners do not cause a memory leak of
the object being listened to since the only reference is from the object
being listened to, to the object that is listening.

-Alex

Re: flash EventDispatcher and Event

[Alex Harui <ah...@adobe.com>]

Hi Mark,

I'm a bit lost on the context here.  The Flash Player is more or less
implementing the W3C DOM Event Specification.  Are you looking to enhance
it?  If so, why?  A whole group of people over at W3C decided this API set
was sufficient.  Or did I miss where they are also updating the
specification?

If this is related to the attempt to know who is listening for events on
an object, keep in mind that I've seen folks want to know that in order to
get all of those listeners to call removeEventListener, but I've never
really understood why, since those listeners do not cause a memory leak of
the object being listened to since the only reference is from the object
being listened to, to the object that is listening.

-Alex

On 7/25/13 4:56 AM, "Kessler CTR Mark J" <ma...@usmc.mil> wrote:

>
>    Ok I've spent a little bit of time looking into both the flash
>EventDispatcher and Event.   To get a good picture of how they interact
>and target the DisplayObjects.  They have quite a few missing properties
>and communicate without using public methods.
>
>    Turns out they just execute code inside the player itself natively
>[1].  So my observations show the missing properties/methods are actually
>controlled in the player which explains a few things.  Giving a small
>example from the flash.events.Event.
>
>
>    When using the preventDefault on an event and be able to check if
>it's prevented...
>
>public native function preventDefault():void;
>public native function isDefaultPrevented():Boolean;
>
>
>    However simple things like being able to see if propogation has been
>stopped, are not present but still being used internally to the player...
>
>public native function stopPropagation():void;
>or
>public native function stopImmediatePropagation():void;
>
>
>    Since the method dispatching the events is in the player and has
>access to the properties that aren't in the event or eventdispatcher.
>
>private native function dispatchEventFunction(event:Event):Boolean;
>
>
>    What this means is your two choices for coming up with a more
>controllable EventDispatcher.
>
>A.  Override the EventDispatcher  methods and run a parallel set of
>methods and properties while still calling  the existing EventDispatcher
>parent (super).  It works well, but seems inefficient to be doing
>everything twice (overridden and super both doing looping operations).
>Less inefficient if using a Dictionary or Map to store the event handlers.
>
>B.  Create a new FlexEventDispatcher / IFlexEventDispatcher and modify
>something like the Flex Events and FlexSprite to work with the new
>dispatcher.    Which seems like an uphill battle to do lots of little
>overrides on the existing base components we have access to.  It would
>only have a functional benefit if a set of components would start using
>it as part of its base.
>
>
>    Looks like Adobe has a tight grasp on this.   Anything else will
>always be a work around.  The only long term way around this type of
>stuff would be to change all the base components and start a new
>component namespace that starts using a base of all Apache Flex made
>classes (no small task in itself).
>
>
>[1] 
>http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/stateme
>nts.html#native
>
>
>-Mark
>