>IIRC, it would require a player change. If you dispatch an event with the
>target already >filled out, the player clones a new instance and dispatches
>that instead.
And by spec, target is immutable so you would be going against specification as
well.
Mike
I seem to remember going down this road before which modifying the event
handling / dispatching / removing before. It's rolling your own entire
eventDispatcher ( IE like starling did) or you'll have to rely on flash player
changes which aren't likely.
The argument that was given about not roll
IIRC, it would require a player change. If you dispatch an event with the
target already filled out, the player clones a new instance and dispatches
that instead.
-Alex
On 9/20/13 9:00 AM, "flexcapaci...@gmail.com"
wrote:
>Would creating an object pooling mechanism for new events improve
>perf
Would creating an object pooling mechanism for new events improve
performance? For example, if instead of calling new FlexEvent() we called
var changeEvent:FlexEvent = FlexEvent.getEventFromPool(FlexEvent.Change);
and then that method checks its object pool for an unused event instead of
creating
