1647080 - WebRender/WR: Scrolling hangs shortly on purecss-francine

Status: REOPENED

(Core :: Graphics: WebRender, enhancement)

Description

[Paul]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.106 Safari/537.36

Steps to reproduce:

Hardware:

• i7-6700k (4/8 cores with Intel HD Graphics 530)
• 32GB DDR4 RAM
• Linux 5.7.4-arch1-1 #1 SMP PREEMPT x86_64
• Xorg / GNOME 3.36
• Firefox Nigthly 79.0a1 (20200620093830) with no extensions

Enabled the following flags:

layers.acceleration.force-enabled: true
gfx.webrender.compositor: true
gfx.webrender.enabled: true

about:support decision log:

HW_COMPOSITING: available by default / force_enabled by user: Force-enabled by pref
OPENGL_COMPOSITING: available by default / force_enabled by user: Force-enabled by pref
WEBRENDER: opt-in by default: WebRender is an opt-in feature / available by user: Force enabled by pref
WEBRENDER_QUALIFIED: available by default
WEBRENDER_COMPOSITOR: disabled by default: Disabled by default / available by user: Enabled via gfx.webrender.compositor
WEBRENDER_ANGLE: opt-in by default: WebRender ANGLE is an opt-in feature

Reproduction:

• Resize the browser
• Go to: https://diana-adrianne.com/purecss-francine/ and resize the browser window's height to fit half of the page
• Scroll completely up and down

Actual results:

The page hangs shortly while scrolling (Mid-page)

Expected results:

Scrolling without hangs. Just like Firefox with WebRender disabled.

Comment 1

[Paul]

Another observation: Scrolling doesn't result in a short hang if the window's height is "large" enough.

Comment 2

[Mayank Bansal]

to repro: Reduce teh height of the browser window (maybe to less than half), and then scroll on the page. There is jank
https://share.firefox.dev/3hFoXxI

Comment 3

[Andrew Osmond [:aosmond] (he/him)]

Similar to the trace on Windows, I see it is spending a lot of time to produce a single frame in the Renderer thread.

Comment 4

[Dzmitry Malyshau [:kvark]]

The renderer frame is indeed mostly busy. Only 32% time it's waiting. More interestingly, 43% total time we spend in CompositorEndFrame, which appears to be de-allocating the composite buffers (every frame!). That's dominating anything else we do on the Renderer thread. Somebody familiar with DC infrastructure on Windows should look at it and figure out if we can re-use the composite buffers instead. Glenn, any ideas?

Comment 5

[Glenn Watson [:gw]]

I spent some time looking into the invalidations. It seems that the clip count dependency changes on some tiles during scrolling, which is unexpected. I'll keep investigating this.

Comment 6

[Glenn Watson [:gw]]

There are two (apparently separate) issues causing unexpected invalidations:

• There are some rotated clip rects that are very large. Due to the way the clip chain handling code works, this can sometimes result in different numbers of clip dependencies for one of the primitives during scrolling.

• There is some kind of rounding / accuracy issue in the local valid rect calculation - sometimes this is different by +/- 1 vertical pixel, which triggers an invalidation.

The first case is the common invalidation case. I confirmed I can work around this by supplying an inflated world rect to the clip-chain building code. However, I need to ponder this and try out some other solutions first, which might be less of a hack.

The second case still needs further investigation.

Comment 7

[Paul]

Gentle ping. Is there some news regarding a fix for this? :)

Comment 8

[Paul]

Gentle ping.

Comment 9

[Glenn Watson [:gw]]

Just tested locally and this seems to be working well for me now, probably as a result of some of the fixes in the last few months related to picture cache invalidation inaccuracies.

I'll close for now, feel free to re-open if it still occurs - it's possible there might be other invalidation accuracy bugs related to zoom / dpi levels etc.

Comment 10

[Paul]

@Glenn Watson I can still reproduce this issue (latest nightly 11-01-2022). Make sure your window's height is not that large.

Comment 11

[Glenn Watson [:gw]]

Unassigning for now, as I'm not actively working on this right now.