What is the nature of the delay of dispatchEvent?

Solar2D General Questions/Discussion
#1

I’ve noticed that using dispatchEvent has a delay. In recent tests, I’ve noticed that this can extend to beyond 150 milliseconds. I’d like to know what the logic is for sending event calls to recipients is and if there is any guarantee of delivery.

#2

Hi Matt,

I’ve not noticed a delay when using that call. Can you show me your code that exhibits it?

Thanks,

Brent

#3

Unfortunately, I don’t think this really applies to simple code - so the sample below does not get affected by the problem because there is not enough going on to warrant delaying of dispatching:

local function newObj( name ) local group = display.newGroup() function group:notice(e) print(name,e.name,e.phase) end Runtime:addEventListener("notice",group) return group end for i=1, 10 do newObj(i) end Runtime:dispatchEvent{ name="notice", phase="first" } Runtime:dispatchEvent{ name="notice", phase="second" } Runtime:dispatchEvent{ name="notice", phase="third" }

I’m guessing that much bigger code, with a lot more routines taking up CPU time, is often enough to cause frames to render. If the dispatch system works as I suspect, it would be ensuring that frames are not interfered with and would only fire off the events when their receiving code does not cause a delay to the overall performance and thus the frame rate.

Put simply, I’m guessing that if the developers code causes the app to slow down, the events will dispatch over a longer period of time.

#4

> If the dispatch system works as I suspect, it would be ensuring that frames are not interfered with …

Just playing devil’s advocate:  how would the dispatch system know this?  The listener is a user-defined function that could do anything, could call other functions (so the dispatch system would have to know about those other functions), etc.

It’s easy to imagine that the dispatch system could have issues with “more complex” code … the question is what complexity matters. How many other event listeners are there?  How many events (or events per second) are there?  Can you time any of the listeners to see if they are either long in duration, or have wide variation in their response times?

 

#5

I imagine that the dispatch system would time each function it calls and if it takes longer than a given threshold time it waits a set time before firing the next event. This would cause a busy system to have delayed event dispatching.

#6

Ahh … I see what you mean now.

@Corona staff:  is there a watchdog timer (or similar) within the event-dispatch system that monitors listener functions?  Is there any coordination between frame-rate events and user-defined ones?

#7

Hi Matt,

I’ve not noticed a delay when using that call. Can you show me your code that exhibits it?

Thanks,

Brent

#8

Unfortunately, I don’t think this really applies to simple code - so the sample below does not get affected by the problem because there is not enough going on to warrant delaying of dispatching:

local function newObj( name ) local group = display.newGroup() function group:notice(e) print(name,e.name,e.phase) end Runtime:addEventListener("notice",group) return group end for i=1, 10 do newObj(i) end Runtime:dispatchEvent{ name="notice", phase="first" } Runtime:dispatchEvent{ name="notice", phase="second" } Runtime:dispatchEvent{ name="notice", phase="third" }

I’m guessing that much bigger code, with a lot more routines taking up CPU time, is often enough to cause frames to render. If the dispatch system works as I suspect, it would be ensuring that frames are not interfered with and would only fire off the events when their receiving code does not cause a delay to the overall performance and thus the frame rate.

Put simply, I’m guessing that if the developers code causes the app to slow down, the events will dispatch over a longer period of time.

#9

> If the dispatch system works as I suspect, it would be ensuring that frames are not interfered with …

Just playing devil’s advocate:  how would the dispatch system know this?  The listener is a user-defined function that could do anything, could call other functions (so the dispatch system would have to know about those other functions), etc.

It’s easy to imagine that the dispatch system could have issues with “more complex” code … the question is what complexity matters. How many other event listeners are there?  How many events (or events per second) are there?  Can you time any of the listeners to see if they are either long in duration, or have wide variation in their response times?

 

#10

I imagine that the dispatch system would time each function it calls and if it takes longer than a given threshold time it waits a set time before firing the next event. This would cause a busy system to have delayed event dispatching.

#11

Ahh … I see what you mean now.

@Corona staff:  is there a watchdog timer (or similar) within the event-dispatch system that monitors listener functions?  Is there any coordination between frame-rate events and user-defined ones?