Closed siusin closed 5 years ago
@rmcilroy @domenic any thoughts on this one?
We provide a non-normative explainer in https://w3c.github.io/requestidlecallback/#idle-periods. Is there a more formal definition that we could draft here?
Could this be defined in terms of https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model ? Something like:
We'd need to do some surgery to make this clean and not refer to steps by number, but that would be my first draft.
TPAC 2017: @rniwa of Apple. Yes, this helps define when Idle period's start may begin if the HTML5 spec is updated in this way. It seems there should be an explicit entry Event Loop after step 7 that this spec should hook.
Yes, I like @domenic's definition above, that sound about right. It would definitely be simpler if we could add an explicit entry into the HTML5 Event Loop after step 7 to hook into. Would someone be willing to add this hook?
I can try to work on it, but if someone else has more time, that'd be ideal. I think the trickiest thing is writing the prose to keep track of all the things before and after step 7, so that the new step can confidently say "I am idle".
@domenic any progress on your front? Got a ping from @plehegar on this one. Philippe, you said this is blocking the HTML spec?
I'll put up a patch today. However, I'm unsure how exactly to integrate. Right now the idling seems a bit implicit in "start an idle period": requestIdleCallback queues a task, that waits for the event loop to become idle (by spinning it until it's empty), and then queues another task to invoke callbacks.
Probably the simplest integration would be if, when the HTML spec noticed it was idle, it called a single algorithm from this spec. Then you wouldn't do any spinning here. But I don't know what a good candidate for that algorithm would be now. Maybe something like "start an idle period" step 5 onward? Although I think it's weird that step 13 queues a task; we're already on the event loop, so that shouldn't be necessarily, unless you want to add opportunities for the UA to run other tasks that might have accumulated during step 5.
Paging @rmcilroy @plehegar for feedback :)
Thanks for looking into this @domenic! I think integrating into step 5 onwards would be the best bet. The main reason to queue another task in step 13 is for the following:
Happy to refactor if you see cleaner ways of meeting these goals though.
[1] Taken from https://w3c.github.io/requestidlecallback/#idle-periods
function doWork(deadline) {
if (deadline.timeRemaining() <= 5) {
// This will take more than 5ms so wait until we
// get called back with a long enough deadline.
requestIdleCallback(doWork);
return;
}
// do work...
}
@rmcilroy @domenic - Is there something delaying progress here?
Not that I'm aware of. If someone were able to drive this to completion that would be great.
I've uploaded https://github.com/w3c/requestidlecallback/pull/75 and https://github.com/whatwg/html/pull/4104 which I think should be sufficient to hook rIC into the HTML spec. @domenic I've gone with a slightly different approach in the event model processing which I think is simpler - in essence instead of working out if we did an idle spin of the loop, instead work out if the next spin of the loop looks to be idle. PTAL, thanks.
Should now be addressed, thanks all.
pass on an AC Review comment:
... from @dwsinger