Handle multiple paint-skip scroll updates within a single transaction
Categories
(Core :: Layout: Scrolling and Overflow, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Bug 1662013 adds a check for when multiple paint-skip transactions occur for a single scrollframe in a single transaction and bails out to a full paint transaction instead. This bug is to store an array of ScrollPositionUpdates instead of a single one in the LayerManager, so that we don't have to bail out to a full paint transaction for this scenario.
|
Assignee | |
Comment 1•4 years ago
|
||
I did a try push with a MOZ_ASSERT(false) on this codepath to see which tests exercise it. There's a lot: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&revision=2fb5cfc7effa3dea060b601e7cd4031db8367397
So when fixing this I don't intend to write a new test, as it seems to have adequate test coverage already.
|
|
Assignee | |
Comment 2•4 years ago
|
||
|
|
Assignee | |
Comment 3•4 years ago
|
||
Sometimes the main thread has multiple scroll position changes that could
individually be propagated to the compositor via paint-skip transactions.
Currently the code doesn't support that; on the second scroll position change
for a given scrollframe it bails out and falls back to a full transaction. This
patch allows this behaviour. The main change is just upgrade the data structure
to store an array of ScrollPositionUpdate instances instead of a single one,
and then plumbing that through. Care is taken to avoid unnecessary copies, by
moving the array where possible.
Pushed by kgupta@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/76cebfb75729 Allow paint-skip transactions to have multiple scroll position updates. r=botond
|
||
Comment 5•4 years ago
|
||
| bugherder | ||
Description
•