Don't allow trivial visual offsets to trigger temporary surface creation
Categories
(Core :: Panning and Zooming, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: kats, Assigned: kats)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
While investigating a tp5o_scroll regression on linux64, I found that the compositor was creating a temporary surface on some composites, due to this code getting triggered. At first I thought it was just a simple floating point error causing the "idealTransform" to end up slightly off from being an integer translation, and so I filed bug 1654353 with a fix to Nudge the matrix back to integers. While that fixed some cases, it didn't fix them all.
Further investigation (see bug 1643223 comment 18) revealed that this was due to APZ code producing a trivial amount of async offset to the compositor. Note that this async offset gets generated with apz.allow_zooming=false as well. The effect is more pronounced with apz.allow_zooming=true though, because with zooming enabled we almost always have a container layer with a framemetrics (the zoom container layer) and a clip, which are required conditions for the temporary surface creation to occur.
|
Assignee | |
Comment 1•5 years ago
|
||
I guess if we always rounded the async offset we gave the compositor this wouldn't be a problem. I don't want to go all the way there, but I have a patch that does something similar in a pretty clean way. Running it through try to ensure it fixes the talos regression now.
|
|
Assignee | |
Comment 2•5 years ago
|
||
Sometimes when sampling the APZC state we get a tiny non-zero async scroll
delta to be applied to the layer transform. This is not user-visible but it
does end up creating temporary surfaces in the layers code, and so is
undesirable. We can avoid this by tweaking the sampled APZC scroll offset
slightly. See comments in the patch for details.
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
Description
•