1750728 - [WebRender] scrolling is very slow on the certain page

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P2)

Description

[Alice0775 White]

Steps to reproduce:

1. Open https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transforms/Using_CSS_transforms#result_2
2. Wait for page load and rendered
3. Try to scroll the page by Keyboard/Mouse wheel/Scroll bar

Actual results:
scrolling is very slow

Expected results:
Not slow

The problem is reproduced in Nightly98.0a1 as well as Firefox91.6.0esr.
The problem is gone in Firefox91.6.0esr if WebRender is disabled.

Comment 1

[Alice0775 White]

Profiler log: https://share.firefox.dev/3fyNaWD

Comment 2

[Sotaro Ikeda [:sotaro]]

:gw, can you comment to this bug? WebRender rendering seemed to take very long time.

Comment 3

[Glenn Watson [:gw]]

I can reproduce this locally, there's (at least) two problems here:

• The size of the div element surfaces that are part of the 3d context are created as 4k x 4k size, and there are a lot of them! (6 faces per cube, 9 cubes). They should be drawn much smaller, I suspect this will either be fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1749380, or at least be much simpler to fix once that lands.

• When scrolling, many of those 3d rendering contexts are invalidating, when they shouldn't be. They should be cached once and the picture cache tiles should remain valid. Interestingly, in some cases with the devtools open, the cubes change visually and scroll without invalidating smoothly.

Comment 4

[Mayank Bansal]

2022-01-22T08:56:41.278000: INFO : Narrowed integration regression window from [7cb0db27, 49dd65ce] (3 builds) to [7cb0db27, 737ecd2c] (2 builds) (~1 steps left)
2022-01-22T08:56:41.286000: DEBUG : Starting merge handling...
2022-01-22T08:56:41.286000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=737ecd2c9621ded2d09d5717065e6c6de206a0c0&full=1
2022-01-22T08:56:41.287000: DEBUG : redo: attempt 1/3
2022-01-22T08:56:41.287000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=737ecd2c9621ded2d09d5717065e6c6de206a0c0&full=1',), kwargs: {}, attempt #1
2022-01-22T08:56:41.288000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2022-01-22T08:56:43.454000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=737ecd2c9621ded2d09d5717065e6c6de206a0c0&full=1 HTTP/1.1" 200 None
2022-01-22T08:56:43.469000: DEBUG : Found commit message:
Bug 1714275 - Establish raster roots for picture cache tiles. r=gfx-reviewers,kvark

This will allow us to select either rasterizing the tiles with a
scale factor of 1.0 (for high performance mode) or at the current
scale of the pinch-zoom (for high quality mode).

Differential Revision: https://phabricator.services.mozilla.com/D116796

2022-01-22T08:56:43.469000: DEBUG : Did not find a branch, checking all integration branches
2022-01-22T08:56:43.469000: INFO : The bisection is done.
2022-01-22T08:56:43.469000: INFO : Stopped

Comment 6

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

The severity field is not set for this bug.
:bhood, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Bob Hood [:bhood]]

Glenn will verify this behavior against https://bugzilla.mozilla.org/show_bug.cgi?id=1749380

Comment 8

[Glenn Watson [:gw]]

I checked locally with https://bugzilla.mozilla.org/show_bug.cgi?id=1749380 applied and this appears to be fixed. We should be able to close this once that patch is reviewed and lands.

Comment 9

[Glenn Watson [:gw]]

For reference, the GPU max times on my machine drop from ~150ms to ~3.5ms.

Comment 10

[Gregory Pappas [:gregp]]

This is somewhat fixed in the latest Nightly, scrolling past the very bottom iframe full of boxes has no jank but scrolling past the top one still does lag on my machine.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transforms/Using_CSS_transforms#result

Comment 11

[Alice0775 White]

(In reply to G from comment #10)

This is somewhat fixed in the latest Nightly, scrolling past the very bottom iframe full of boxes has no jank but scrolling past the top one still does lag on my machine.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transforms/Using_CSS_transforms#result

Yes, Bug 1749380 improved the scrolling performance for the very bottom iframe example. However, still slow(jank) for the middle one.

Comment 12

[Glenn Watson [:gw]]

Yup, with gfx.webrender.debug.render-targets enabled, I can still see some very large targets being created. So the patches in https://bugzilla.mozilla.org/show_bug.cgi?id=1749380 incidentally fix some of the issues in this bug, but not all. We'll need to investigate why it's creating surfaces that large and how / where to determine that only a small surface is needed here.

Comment 13

[Gregory Pappas [:gregp]]

The lag on the very bottom iframe example has once again returned in the latest Nightly.
Last good revision: 2c26f3ae2371ac5ce9e09b263f70772bb0e7cbe6
First bad revision: 9f3cb0197f1ff639627e97ea474596fc6ccb2a1f
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2c26f3ae2371ac5ce9e09b263f70772bb0e7cbe6&tochange=9f3cb0197f1ff639627e97ea474596fc6ccb2a1f

Comment 14

[Glenn Watson [:gw]]

Likely this is because that WR change means it takes into account the requested scale coming from the Gecko display list. Very interesting finding is that when the devtools inspector is open, the render target sizes are small and the scrolling is fast. So I suspect that the Gecko display list itself might be different (or, it might be a WR bug related to scale selection within iframes).

Comment 15

[Glenn Watson [:gw]]

There's two issues here:

1. Gecko is asking WR to rasterize these surfaces with perspective in screen mode and WR is not very clever at estimating an appropriate device-pixel scale when there is perspective present (resulting in large scale factors when devtools is not open, due to the nature of the transform matrices).

2. Gecko should ideally not be asking for screen space raster mode here, and should ask for local raster mode any time there is a perspective.

If we can fix (2) we can probably completely remove the WR functionality in (1).

I put up a try run at [1] which unconditionally just enables local raster mode. Let's see what that breaks and perhaps we can start with a subset of stacking contexts (e.g. ones that have a perspective transform).

[1] https://treeherder.mozilla.org/jobs?repo=try&revision=83e9bf003e1054e8577a9860efd3eed06381c332

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Seems greenish other than some anti-aliasing changes which are maybe to be expected? The change to make it work on perspective should be trivial but if you need help with that lmk.

Comment 17

[Alice0775 White]

(In reply to Alice0775 White from comment #11)

(In reply to G from comment #10)

This is somewhat fixed in the latest Nightly, scrolling past the very bottom iframe full of boxes has no jank but scrolling past the top one still does lag on my machine.
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transforms/Using_CSS_transforms#result

Yes, Bug 1749380 improved the scrolling performance for the very bottom iframe example. However, still slow(jank) for the middle one.

This partial improvement by Bug 1749380 seems to have been spoiled by Bug 1757002 . Scrolling has worsened again.
I will file a new bug for this.

Comment 19

[Glenn Watson [:gw]]

This is fixed by the work in bug 1764875.