1872487 - create less WebRenderLayerScrollData

Status: RESOLVED FIXED

(Core :: Panning and Zooming, enhancement, P2)

Comment 1

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 1872487. Create less WebRenderLayerScrollData. r?botond

In order to create less WebRenderLayerScrollData currently we use a deferred transform item

https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82

We don't need a WebRenderLayerScrollData for very transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.

However this optimization can lead to use creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.

WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.

This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.

I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.

Comment 2

[Timothy Nikkel (:tnikkel)]

Attachment: sctr.html

This reproduces the basic problem in a simplified form.

It takes the important pieces from the speedometer test. When the test is run, it's run in an iframe that has a transform, so it's important to use the test as it is when it is run. Opening the page outside of the runner will likely be different, ie the iframe might be skipped and the page will be top level.

One can inspect this environment using https://speedometer-preview.netlify.app/interactiverunner
Select the test (svelte complex dom) and then click step. The test will then be paused and can be inspected.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:tnikkel, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 4

[Timothy Nikkel (:tnikkel)]

Just need to update it to the minor review comments.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Given that there's an active JIRA ticket for this bug, I am setting P2.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb7b045d24f7
Create less WebRenderLayerScrollData. r=botond

Comment 7

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/bb7b045d24f7