ordering of EnterFrame events

If I have added Event.ENTER_FRAME listeners to different components, how can I set or know the ordering of when these events will be fired on each enterFrame?

Instead of adding enterFrame listeners to individual elements, is it better practice to have one element which listens for enterFrame events, and has an array of elements 开发者_开发知识库needing updating on enterFrames, thereby making it easy to organize and change the firing order of these events?

You can prioritize event listeners, thereby ordering the execution of them. Use the fourth property of addEventListener(), an integer that indicates priority. Event listeners added with a high priority integers will be executed before those with lower priority. See the addEventListener() reference for more information.

But you are also right that it is usually a better idea to create your own update manager. This is because event listeners require an Event (or sub-class thereof) to be instantiated, which can greatly affect performance (instantiation is one of the most heavy tasks in the Flash runtime.) This is especially unfortunate with ENTER_FRAME events, as you will often not use the event object anyway.

Create a manager class, from which other parts of your application may subscribe to update callbacks. Whenever a callback is registered, add one ENTER_FRAME (or TimerEvent.TIMER) event listener inside the manager class that invokes all callbacks. When the last callback is removed, remove the event listener as well.

While on the topic of events and performance, you might be interested to know that for events that bubble (most interaction events that take place in the display list), a new event object is created for each dispatcher that the event passes during the bubbling! It's always a good idea to remove event listeners whenever you don't need them.

You cannot guarantee the execution order for event listeners.

... is it better practice to have one element which listens for enterFrame events, and has an array of elements needing updating on enterFrames ...

This really depends on the use case. In some cases, for example a particle system, probably yes. If you have dozens of objects that form a logical set then it often makes sense to do much of the collective logic in a single manager type class. That could include a set specific update loop. This can save you quite a bit of overhead in general.

Then again, if all you are doing is:

function managerUpdate(event:Event):void
{
    for(var thing:Object in set)
    {
        thing.update();
    }
}

Then you aren't really saving that much overhead at all. Of course, in the above case, you can control the ordering of your set. You could also cull it on a frame-by-frame basis.

Also consider if there are calculations or other algorithms that can be hoisted from within the update of set instances into a manager and passed through parameters.

Without more information on your specific use case I can't be more specific.

It's probably based on the order in which you've subscribed to the event, as it gets added to a collection that is probably being looped through when firing the event, but I would not trust this as the documentation does not guarantee this.

Instead of the order of the events is important, I would create my own collection of delegates, and have one subscriber to the event which iterates over your own collection, calling each delegate, waiting for it to return, then calling the next. This way you can be sure of the order of events. I'm just like to be more cautious on these things.