When are timers executed?

[krystian6]

Hi,

Due to bug in Corona setSequence/setFrame handling I depend on timers a lot.
I create timers with 1 ms delay to setFrame on an animation.

Nevermind that.

What I see currently, is that when I create a timer with 1 ms delay in enterFrame it will be executed after another enter frame.

What I would expect:

- enter frame  
 - creation of a timer  
-enter frame finished  
- timer is executed  
- enter frame  

What is happening right now:

- enter frame  
 - creation of a timer  
- enter frame is finished  
- another enter frame  
- another enter frame is finished  
- timer is executed  

Timing is correct, it takes more than 1 ms after the timer is created to leave the enter frame listener.

Anyway… could someone confirm how/when timers are executed? [import]uid: 109453 topic_id: 33389 reply_id: 333389[/import]

[richard9]

Probably only Corona can explain how the SDK stack works in terms of execution order, but what I can say is that you shouldn’t rely on timings less than 1 frame (17ms) and ideally shouldn’t rely on anything less than 2 frames (or 1 frame @ 30fps, which is 34ms)

Lua isn’t exactly in order execution but specifically with Corona you’ll notice virtually no difference in timers with 1ms vs 30ms on them… [import]uid: 41884 topic_id: 33389 reply_id: 132606[/import]

[richard9]

Probably only Corona can explain how the SDK stack works in terms of execution order, but what I can say is that you shouldn’t rely on timings less than 1 frame (17ms) and ideally shouldn’t rely on anything less than 2 frames (or 1 frame @ 30fps, which is 34ms)

Lua isn’t exactly in order execution but specifically with Corona you’ll notice virtually no difference in timers with 1ms vs 30ms on them… [import]uid: 41884 topic_id: 33389 reply_id: 132607[/import]

[krystian6]

Thanks Richard,

I’m setting 1 because I want it to be executed as soon as possible.

I simply assumed that timers are executed after enterFrame and the execution is based on a simple check:

TimeWhenTimerShouldBeRun \<= now [import]uid: 109453 topic_id: 33389 reply_id: 132620[/import]

[richard9]

Well the basic problem is that Corona can’t actually read and execute your code in less than 1ms. It’s fast, but not 2000fps fast. Certain code is faster than others, but executing code through a timer means it runs the timer first, then the code, so you’re basically putting multiple layers of execution in front of it.

(I found this out when making a number counting function - if you want to count numbers really fast at some point you need to detect the speed and increment by 2 or more simply because it can’t respond fast enough.)

I’m not sure how timer.* works with regards to enterFrame, it’s possible it works as you say or it could be triggered by some internal timing register system.

Is there a reason why sequence/frame aren’t working for you? I thought they fixed most of those problems… [import]uid: 41884 topic_id: 33389 reply_id: 132622[/import]

[krystian6]

richard, thanks for your support, but you’re kind of off topic with your explanations.

Timers are simple objects which hold [apart from other things]:

1. reference to a function to call
2. time when this function should be called [this is your delay you stated when creating timer + os.time() when the timer was created]

There is an order of execution of events and timers [I’m not exactly sure how it’s maintained, but from what I can see it’s divided into event types and then within same type it’s based on order of creation - I might be wrong here, I didn’t investigate it deep enough to be sure, but it doesn’t matter in this case].

Although it doesn’t matter, let’s assume it works like this (os.time of execution)

enter frame1 (100)  
codeA  
enter frame listeners1 (150)  
sprite1 (200)  
sprite listeners1 (250)  
timers1 (300)  
enter frame2 (400)  
enter frame listeners2 (450)  
sprite2 (500)  
sprite listeners2 (550)  
timers2 (600)  
timerA  

Let’s assume, in codeA block I’m creating a timer:

timer.performWithDelay(1, function() print("foobar") end)  

I would assume this timer to be executed within timers1 block, but it’s executed within timers2.

Is this correct?
Is there something wrong with my assumption on how the timers work?

I would like to get an answer, and not a guess.
We could guess all night long if not the fact that every hour with me messing with the crap that I get because of broken setSequence/setFrame handling means financial losses I can barely take right now.

[sorry for the rant, but each error I get because of this is bringing me closer to the edge…]

Oh…
The setSequence/setFrame issue:
http://developer.coronalabs.com/forum/2012/10/11/sprite-new-animation-setsequencesetframe-function-strange-behavior [import]uid: 109453 topic_id: 33389 reply_id: 132623[/import]

[StarCrunch]

What about with a 0 ms delay?

If I had to guess, new timers might get put into a waiting list, and then merged in after regular timers run, maybe to make it easier / more consistent to manage stuff like launching new timers inside old ones.

A substitute might be something like this:

[lua]-- Somewhere early in your program
local StuffToDo = {}

timer.performWithDelay(1, function(event)
– Process our stuff
for _, stuff in ipairs(StuffToDo) do
if stuff.what == “sprite_frame” then
– Do something with sprite…
– Other options, etc.
end
end

– Clear our list
for i = 1, #StuffToDo do
StuffToDo[i] = nil
end
end, 0) – Note the 0: do each frame

– Later… add something to do
StuffToDo[#StuffToDo + 1] = { what = “sprite_frame”, target = sprite }[/lua]

The frame delay is irrelevant, then. Obviously, tailor as needed. [import]uid: 27791 topic_id: 33389 reply_id: 132646[/import]

[krystian6]

That’s an idea.
I’m already using pausable transitions and timers from code exchange [TNT] to manage my normal timers and transitions, but for this hack this might be an idea.

Thanks! [import]uid: 109453 topic_id: 33389 reply_id: 132651[/import]

[richard9]

Probably only Corona can explain how the SDK stack works in terms of execution order, but what I can say is that you shouldn’t rely on timings less than 1 frame (17ms) and ideally shouldn’t rely on anything less than 2 frames (or 1 frame @ 30fps, which is 34ms)

Lua isn’t exactly in order execution but specifically with Corona you’ll notice virtually no difference in timers with 1ms vs 30ms on them… [import]uid: 41884 topic_id: 33389 reply_id: 132606[/import]

[richard9]

Probably only Corona can explain how the SDK stack works in terms of execution order, but what I can say is that you shouldn’t rely on timings less than 1 frame (17ms) and ideally shouldn’t rely on anything less than 2 frames (or 1 frame @ 30fps, which is 34ms)

Lua isn’t exactly in order execution but specifically with Corona you’ll notice virtually no difference in timers with 1ms vs 30ms on them… [import]uid: 41884 topic_id: 33389 reply_id: 132607[/import]

[krystian6]

Thanks Richard,

I’m setting 1 because I want it to be executed as soon as possible.

I simply assumed that timers are executed after enterFrame and the execution is based on a simple check:

TimeWhenTimerShouldBeRun \<= now [import]uid: 109453 topic_id: 33389 reply_id: 132620[/import]

[richard9]

Well the basic problem is that Corona can’t actually read and execute your code in less than 1ms. It’s fast, but not 2000fps fast. Certain code is faster than others, but executing code through a timer means it runs the timer first, then the code, so you’re basically putting multiple layers of execution in front of it.

(I found this out when making a number counting function - if you want to count numbers really fast at some point you need to detect the speed and increment by 2 or more simply because it can’t respond fast enough.)

I’m not sure how timer.* works with regards to enterFrame, it’s possible it works as you say or it could be triggered by some internal timing register system.

Is there a reason why sequence/frame aren’t working for you? I thought they fixed most of those problems… [import]uid: 41884 topic_id: 33389 reply_id: 132622[/import]

[krystian6]

richard, thanks for your support, but you’re kind of off topic with your explanations.

Timers are simple objects which hold [apart from other things]:

1. reference to a function to call
2. time when this function should be called [this is your delay you stated when creating timer + os.time() when the timer was created]

There is an order of execution of events and timers [I’m not exactly sure how it’s maintained, but from what I can see it’s divided into event types and then within same type it’s based on order of creation - I might be wrong here, I didn’t investigate it deep enough to be sure, but it doesn’t matter in this case].

Although it doesn’t matter, let’s assume it works like this (os.time of execution)

enter frame1 (100)  
codeA  
enter frame listeners1 (150)  
sprite1 (200)  
sprite listeners1 (250)  
timers1 (300)  
enter frame2 (400)  
enter frame listeners2 (450)  
sprite2 (500)  
sprite listeners2 (550)  
timers2 (600)  
timerA  

Let’s assume, in codeA block I’m creating a timer:

timer.performWithDelay(1, function() print("foobar") end)  

I would assume this timer to be executed within timers1 block, but it’s executed within timers2.

Is this correct?
Is there something wrong with my assumption on how the timers work?

I would like to get an answer, and not a guess.
We could guess all night long if not the fact that every hour with me messing with the crap that I get because of broken setSequence/setFrame handling means financial losses I can barely take right now.

[sorry for the rant, but each error I get because of this is bringing me closer to the edge…]

Oh…
The setSequence/setFrame issue:
http://developer.coronalabs.com/forum/2012/10/11/sprite-new-animation-setsequencesetframe-function-strange-behavior [import]uid: 109453 topic_id: 33389 reply_id: 132623[/import]

[StarCrunch]

What about with a 0 ms delay?

If I had to guess, new timers might get put into a waiting list, and then merged in after regular timers run, maybe to make it easier / more consistent to manage stuff like launching new timers inside old ones.

A substitute might be something like this:

[lua]-- Somewhere early in your program
local StuffToDo = {}

timer.performWithDelay(1, function(event)
– Process our stuff
for _, stuff in ipairs(StuffToDo) do
if stuff.what == “sprite_frame” then
– Do something with sprite…
– Other options, etc.
end
end

– Clear our list
for i = 1, #StuffToDo do
StuffToDo[i] = nil
end
end, 0) – Note the 0: do each frame

– Later… add something to do
StuffToDo[#StuffToDo + 1] = { what = “sprite_frame”, target = sprite }[/lua]

The frame delay is irrelevant, then. Obviously, tailor as needed. [import]uid: 27791 topic_id: 33389 reply_id: 132646[/import]

[krystian6]

That’s an idea.
I’m already using pausable transitions and timers from code exchange [TNT] to manage my normal timers and transitions, but for this hack this might be an idea.

Thanks! [import]uid: 109453 topic_id: 33389 reply_id: 132651[/import]