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

Investigate adding dedicated task sources #221

Open
tobie opened this issue May 27, 2017 · 3 comments
Open

Investigate adding dedicated task sources #221

tobie opened this issue May 27, 2017 · 3 comments

Comments

@tobie
Copy link
Member

tobie commented May 27, 2017

This might be useful (or not?) to enable prioretizing sensor queues, maybe even between different types of sensors.

Need to investigate how this is handled at the spec and implementation level

@anssiko
Copy link
Member

anssiko commented May 30, 2017

The HTML spec leaves the task queue prioritization to implementations. I believe an implementation is most of the time in the best position to determine which task to run and when, all things considered, see https://html.spec.whatwg.org/#task-source. In normative prose https://html.spec.whatwg.org/#event-loop-processing-model this is simply:

The user agent may pick any task queue.

While we currently do not force a particular task to be of higher priority, requestIdleCallback API provides means to explicitly request a particular task to be executed only during the idle time between the frames. If used appropriately, this API will help keep jank away in use cases that involve sensors too.

@tobie
Copy link
Member Author

tobie commented May 30, 2017

The HTML spec leaves the task queue prioritization to implementations. I believe an implementation is most of the time in the best position to determine which task to run and when, all things considered, see https://html.spec.whatwg.org/#task-source. In normative prose https://html.spec.whatwg.org/#event-loop-processing-model this is simply:

The user agent may pick any task queue.

Agreed. The idea wasn't to specify prioritization here, but eventually to provide hooks in the spec(s) to make that easier, for example by using two different task source, one when latency is critical and one when it isn't.

While we currently do not force a particular task to be of higher priority, requestIdleCallback API provides means to explicitly request a particular task to be executed only during the idle time between the frames. If used appropriately, this API will help keep jank away in use cases that involve sensors too.

That seems like an orthogonal issue.

@alexshalamov
Copy link

Moving to Level2. There are ongoing activities related to throttled / unthrottled / suspendable task sources, we should definitely investigate those concepts in relation to Sensors.

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

No branches or pull requests

3 participants