Re: [spec-reviews] requestIdleCallback (#70)

On Friday 2015-10-23 12:09 +0900, L. David Baron wrote:
> That said, I'm not against all constraints in the processing model; a number of the other constraints (e.g., relating to the relative order of idle callbacks, or the fact that each idle callback is called from a separate queued task posted after the previous one finishes) seem good.

On the flip side, there are also downsides to some of the other constraints:  for example, they don't allow implementations all that much leeway to prioritize a visible tab over a hidden tab (presuming they share an event loop) within a single idle period, beyond allowing the visible tab to have its first idle callback executed before the hidden tabs' first idle callback, and limiting all of the hidden tabs to exactly one idle callback by terminating the repeating (which would then be wasteful if the visible tab didn't have enough work to finish the idle period).

I'm also wondering if it's less than ideal that there's one "invoke idle callbacks algorithm" _per document_ as a queued task during the idle period.  I was thinking that the queueing of a separate task for each callback meant that tasks queued from a callback run before the next idle callback (which is probably good for memory access locality and thus performance, if the tasks are small, at least assuming implementations don't blow all CPU caches just by queueing and executing a task).  But now I realize (I think) that that isn't true; tasks queued from an idle callback run after the next idle callback for all the other documents, but before the next idle callback for the same document.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/70#issuecomment-150448988