Skip to content
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

Merged
merged 7 commits into from
Oct 25, 2018
Merged

Conversation

rmcilroy
Copy link
Contributor

@rmcilroy rmcilroy commented Oct 18, 2018

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 )

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.
@rmcilroy
Copy link
Contributor Author

@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?

Copy link
Member

@domenic domenic left a 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.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Outdated Show resolved Hide resolved
source Show resolved Hide resolved
@rmcilroy
Copy link
Contributor Author

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?

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.

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.

Should be done, thanks.

@domenic
Copy link
Member

domenic commented Oct 24, 2018

Great! Ready to merge once w3c/requestidlecallback#75 gets merged.

@rmcilroy
Copy link
Contributor Author

w3c/requestidlecallback#75 has now been merged, so I think we should be good to go here :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

2 participants