-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate with requestIdleCallback #4104
Conversation
This adds a hook to the event loop's processing model to define when the start of an idle period should begin. This deals with the issue in w3c/requestidlecallback#70 and calls directly into the "start an idle period" algorithm, instead of that algorithm having to having to spin the event loop. This change depends on the PR in w3c/requestidlecallback#75.
@domenic could you please take a look, I think this would be sufficient to hook request idle callback into the HTML spec - I don't think we need to know whether the current event loop was an idle loop, just if it looks like the next loop will be. What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fascinating, this is much nicer than my original. Mostly seems reasonable, but we need to do the appropriate loop to all the Windows in question.
Let's note that this seems to supercede #3570. Unlike that PR, this one doesn't deal with notifying about rejected promises or cleaning up IDB transactions. Is that difference intentional?
Finally, I believe you work for Google, right? In which case please publicize your organization membership, instead of signing up as an individual contributor. Let me know if I got that wrong though.
I've added a note. Yes not notifying on rejected promises or IDB transactions is intentional. If a rejected promise is being notified the algorithm posts a task, so the current PR should avoid starting an idle period then (since it checks for the task queue being empty). For cleaning up IDB transactions, since this happens after tasks and microtasks have already been run, the transactions should be cleaned up by the time we reach this point.
Should be done, thanks. |
Great! Ready to merge once w3c/requestidlecallback#75 gets merged. |
w3c/requestidlecallback#75 has now been merged, so I think we should be good to go here :). |
This adds a hook to the event loop's processing model to define when the start
of an idle period should begin. This deals with the issue in
w3c/requestidlecallback#70 and calls directly into the "start an idle period"
algorithm, instead of that algorithm having to having to spin the event loop.
This change depends on the PR in w3c/requestidlecallback#75. It supercedes
#3570, avoiding the need for notifying about rejected promises or cleaning up
IDB transactions.
/infrastructure.html ( diff )
/references.html ( diff )
/webappapis.html ( diff )