Frame loop execution order

[primoz.cerar]

This is a question for the Corona staff.

I would like to know what is the frame execution order in corona. What I mean is when do certain events fire in a frame loop. What I’m looking for is something like this:

1. Wait for next frame

2. …

3. Call all enterFrame listeners

4. Call all touch listeners

5. Update physics

6. …

7. Update screen

I am guessing that all the touch events get fired at the same time as enterFrame or am I wrong?

I’m also guessing that transitions and timers get fired from enterFrame listeners as well?

If so which gets called first transitions, timers, touch events, enterFrame listeners …

I am trying to do some calculations where this info would be a factor.

Thank you.

[walter]

At a top-level granularity, the order is roughly:

1. User input events

2. Corona “tick”

More specifically, user input events break into things like touch events, accelerometer events, etc that are driven by the user and can trigger listeners in Lua. (Note: on Android, these events can appear to come in all at once b/c they are queued from a different thread, so you should leverage the time-related properties in the event itself instead of polling the time yourself!)

The Corona “tick” breaks down into:

1. Sprites (if any) are updated to their new frame

2. Physics world steps

3. EnterFrame listeners are invoked. This triggers transitions/timers as they are layered on top of enterFrame.

4. Render update

[primoz.cerar]

Thank you for the clarification.

I am hoping you could answer this more specific question.

I have some transitions that I calculate in enterFrame as they can change during the time of the transition itself and can be more of them updating the same object and such. The way I calculate the current position is

local t = system.getTimer() - tr.startTime

Now if the enterFrame and other events that might be running take some time to complete (which varies) this can have an impact on the smoothness of the transition.

I guess what I would like to know is if there is way to get the exact time the frame will be rendered to do the calculations. Or is this relative to the time the events take to process?

I guess it comes down to this:

Is the order like this:

  -render update

  -wait for next frame

  -call events

  -render update

or is it like this:

  -render update

  -call events

  -wait for next frame

  -render update

Where does the wait come in? And if it’s the second order that is correct, can I get the next update time somehow? Or last update time would be useful also as I can calculate the next one based on fps.

Thank you.

[primoz.cerar]

Can you give me a hint on this? Just when the wait comes in would be a good start.

[walter]

Multiple user input events (#1) can happen in between each tick (#2). The fps controls when the “Tick” happens, e.g for 30 fps, it’s every 1/30 sec. Obviously, you can do things to hurt performance and muck with timing, e.g. your enterFrame listener takes too long, or you have a million physics bodies on screen at once.

[primoz.cerar]

I see. So the wait is before enterFrame. Then what I’m trying to achieve would be difficult.

Thank you for the info.

[walter]

At a top-level granularity, the order is roughly:

1. User input events

2. Corona “tick”

More specifically, user input events break into things like touch events, accelerometer events, etc that are driven by the user and can trigger listeners in Lua. (Note: on Android, these events can appear to come in all at once b/c they are queued from a different thread, so you should leverage the time-related properties in the event itself instead of polling the time yourself!)

The Corona “tick” breaks down into:

1. Sprites (if any) are updated to their new frame

2. Physics world steps

3. EnterFrame listeners are invoked. This triggers transitions/timers as they are layered on top of enterFrame.

4. Render update

[primoz.cerar]

Thank you for the clarification.

I am hoping you could answer this more specific question.

I have some transitions that I calculate in enterFrame as they can change during the time of the transition itself and can be more of them updating the same object and such. The way I calculate the current position is

local t = system.getTimer() - tr.startTime

Now if the enterFrame and other events that might be running take some time to complete (which varies) this can have an impact on the smoothness of the transition.

I guess what I would like to know is if there is way to get the exact time the frame will be rendered to do the calculations. Or is this relative to the time the events take to process?

I guess it comes down to this:

Is the order like this:

  -render update

  -wait for next frame

  -call events

  -render update

or is it like this:

  -render update

  -call events

  -wait for next frame

  -render update

Where does the wait come in? And if it’s the second order that is correct, can I get the next update time somehow? Or last update time would be useful also as I can calculate the next one based on fps.

Thank you.

[primoz.cerar]

Can you give me a hint on this? Just when the wait comes in would be a good start.

[walter]

Multiple user input events (#1) can happen in between each tick (#2). The fps controls when the “Tick” happens, e.g for 30 fps, it’s every 1/30 sec. Obviously, you can do things to hurt performance and muck with timing, e.g. your enterFrame listener takes too long, or you have a million physics bodies on screen at once.

[primoz.cerar]

I see. So the wait is before enterFrame. Then what I’m trying to achieve would be difficult.

Thank you for the info.

[tschussler]

@Walter - am I correct in that timers are only serviced once per frame or “tick”?  Ie. every 16.7ms if the config.lua fps is set to 60?

I’m seeing situations where it appears that timer.performWithDelay is not firing accurately - and I’m trying to understand why.  Sometimes, I am finding that it appears to firing early and I’m suspecting that the Corona engine might be evaluating the timer and rounding down the delay and firing the timer if the remainder is less than the next frame duration (e.g.16.7ms).

[walter]

Yes, timers are built on top of enterFrame listeners, which are fired once per frame.

[tschussler]

@Walter - am I correct in that timers are only serviced once per frame or “tick”?  Ie. every 16.7ms if the config.lua fps is set to 60?

I’m seeing situations where it appears that timer.performWithDelay is not firing accurately - and I’m trying to understand why.  Sometimes, I am finding that it appears to firing early and I’m suspecting that the Corona engine might be evaluating the timer and rounding down the delay and firing the timer if the remainder is less than the next frame duration (e.g.16.7ms).

[walter]

Yes, timers are built on top of enterFrame listeners, which are fired once per frame.