Making input tasks more strictly aligned with vsync
Categories
(Core :: Performance: General, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox89 | --- | fixed |
People
(Reporter: sefeng211, Assigned: sefeng211)
References
Details
Attachments
(6 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
The idea is to be able to handle more input tasks before vsync, and doing fewer input tasks while vsync.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 1•5 years ago
|
||
Introduce a new TaskManager called HighPriorityTaskManager for
EventQueuePriority::High tasks.
| Assignee | ||
Comment 2•5 years ago
|
||
This patch introduces a new way to way to schedule input tasks, such
that input tasks remain at InputHigh priority normally, however, when
there's a pending High priority task (Vsync tasks) in the task queue, we
increase the priority of input tasks from InputHigh to Vsync to
process the pending input tasks.
There are two restrictions to ensure we don't delay vsync too much:
- There's a hard limit duration
- We won't process the input tasks that are newly added after we've
started to process the current number of input tasks
Depends on D109498
Updated•5 years ago
|
Updated•5 years ago
|
| Assignee | ||
Comment 3•5 years ago
|
||
High priority is being used for vsync tasks, so we should rename it to
make it clear, and renaming it also makes our priority naming less
confusing.
Updated•5 years ago
|
Updated•5 years ago
|
| Assignee | ||
Comment 4•5 years ago
|
||
Depends on D109499
| Assignee | ||
Comment 5•5 years ago
|
||
Some tests need to wait for a full tick cycle to ensure the expected
input tasks are run.
Comment 7•5 years ago
|
||
Backed out 5 changesets (Bug 1697585) for causing build bustages on nsTimerImpl.h
https://hg.mozilla.org/integration/autoland/rev/dc555adb9f36ecb4caeba9d1b56f4d3fd1f9f1ba
Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&revision=e9e4a710e7d15a3ace7764483a5cfceb6e2713c9&selectedTaskRun=IrgdUtALQ9m-hNm-gghqiQ.0
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=335564750&repo=autoland&lineNumber=49213
| Assignee | ||
Comment 8•5 years ago
|
||
Currently, for auto scroller, when a mousedown happens, a possible run order is that
mousedown(parent process) -> scroll stopped (parent process) ->
mousedown(child process), so that the last mousedown(child process)
would start the scrolling again.
This patch adds a new check to the last mousedown(child process)
handler, to not starting the scrolling again if preventClickEvent has
been called on this event.
Comment 10•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/8ed6175e0c7b
https://hg.mozilla.org/mozilla-central/rev/4031cca20f28
https://hg.mozilla.org/mozilla-central/rev/c206669072a4
https://hg.mozilla.org/mozilla-central/rev/ca2243d8f565
https://hg.mozilla.org/mozilla-central/rev/eebe83ba4c97
https://hg.mozilla.org/mozilla-central/rev/0ce8cafaccaf
| Assignee | ||
Updated•5 years ago
|
Updated•4 years ago
|
Description
•