search

w3c / setImmediate

This repo defines an interface for web applications to flush the browser event queue and receive an immediate callback.
Other
3 stars 8 forks source link

spec does not mentioned that setImmediate is implemented as a low-priority idle queue #2

Open toddreifsteck opened 9 years ago

toddreifsteck commented 9 years ago

Changing issue text to be more accurate

igrigorik commented 9 years ago

What happens in the case where my application is consistently taking ~16ms to process each frame and there is no idle time (e.g. my game loop is just barely keeping up), will the setImmediate queue be delayed indefinitely?

tobint commented 9 years ago

I think that's an implementation detail that can be left up to the UA. I think you'll find it rare to have a game loop that blocks exactly a full frame each time. Either the frame will blow the budget, and bleed into the next frame, creating idle space in that frame to process the queue, or you'll leave yourself some space in the current frame. Yes, it is possible to fill the frame largely leaving it so the callback doesn't get serviced, but it's unlikely to leave zero budget for an extended period of time. I don't think you'd have an issue if the callback in setImmediate was processed at low priority. The aim is reducing CPU utilization and power consumption and occasionally has the benefit of improving performance.

igrigorik commented 9 years ago

@tobint I don't disagree, but having previously spent many years in analytics world... I know that there is very low tolerance for "it'll execute sometime; there is a tiny chance it won't" type of semantics, and I envision analytics and related use cases being one of the key customers for an API like this, hence the question.