DOM events are great for asynchronous processing, but they are also troublesome for allowing some actions to be done outside of the melonJS main thread. #346 and #358 are examples of how DOM events can interact with melonJS poorly by creating race conditions. #395 is also related, since the DOM events are only enabled by specific user-initialization calls.
In this ticket, I want to expand upon minpubsub to do all event handling within the melonJS main thread (which starts execution in _renderframe() : https://github.com/melonjs/melonJS/blob/master/src/state/state.js#L397)
Conceptually, any process which fires off-thread (DOM events, timer callbacks -- including Function.prototype.defer(), etc.) needs to immediately place a callback into a list where the main thread can run it. And we will expose this API for any custom events that a user might want to add. This is the only way to guarantee that async callbacks will be called without races.
I've seen a similar API in libraries like Chipmunk-physics, where the user may want to perform specific actions at certain points within the collision phases, for example. With melonJS, we might have similar event phases, like pre-update, post-update, pre-draw and post-draw (to name the obvious ones)
post-update and pre-draw are separate event phases because the timing of these phases will be different when frame skipping is enabled -- see #346 (comment) for a detailed explanation.
That will allow us to do things like: handle all input events in the pre-update phase, and handle all deferred calls in the post-draw phase. Or switching things around as necessary.
DOM events are great for asynchronous processing, but they are also troublesome for allowing some actions to be done outside of the melonJS main thread. #346 and #358 are examples of how DOM events can interact with melonJS poorly by creating race conditions. #395 is also related, since the DOM events are only enabled by specific user-initialization calls.
In this ticket, I want to expand upon minpubsub to do all event handling within the melonJS main thread (which starts execution in
_renderframe(): https://github.com/melonjs/melonJS/blob/master/src/state/state.js#L397)Conceptually, any process which fires off-thread (DOM events, timer callbacks -- including
Function.prototype.defer(), etc.) needs to immediately place a callback into a list where the main thread can run it. And we will expose this API for any custom events that a user might want to add. This is the only way to guarantee that async callbacks will be called without races.I've seen a similar API in libraries like Chipmunk-physics, where the user may want to perform specific actions at certain points within the collision phases, for example. With melonJS, we might have similar event phases, like
pre-update,post-update,pre-drawandpost-draw(to name the obvious ones)post-updateandpre-draware separate event phases because the timing of these phases will be different when frame skipping is enabled -- see #346 (comment) for a detailed explanation.That will allow us to do things like: handle all input events in the
pre-updatephase, and handle all deferred calls in thepost-drawphase. Or switching things around as necessary.