1724129 - https://codepen.io/trangthule/pen/vYmpNYR is very slow

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Mayank Bansal]

https://share.firefox.dev/3jlQyWx

Comment 1

[Mayank Bansal]

Attachment: abut:supprt

Comment 2

[Mayank Bansal]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a3941f42e66295031c2a6bf7b188d4c48a7ae624&tochange=92c11f0bf14b71b70bec5351212ae237707f4a62

Comment 3

[Alice0775 White]

I can reproduce the issue in Nightly92.0a1 Windows10 with WebRender.
It seems there are several regression.

Regression window used local cached build are as follows.

#1 Regression window(Animates like a hiccup.):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6c10970490f3cc19e644964f583be1a047c08b2c&tochange=3d91ba9e1d25d47c742436b5aa8bb309fb67b365
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a0d10a7e5c3f219e8346667b107cb02506cbbdd8&tochange=0356e5fff183afb22f6eeca0e53ab8ec56745fad

So, suspect: Bug 1559861

#2 Regression Further worsening. Peak memory usage increased.
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fa0afb4328103e7e61b98b3b2706891334eb2926&tochange=7f0b0cbecd946aee526a869853a46a14ee44b1f9
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2069d33fce0318e442afb5111ccd2a96a2b87bf8&tochange=f54f65e5c5b4f0089ebc942ba9552b61e99e1c24

So, Suspect: Bug 1646279

Comment 4

[Sotaro Ikeda [:sotaro]]

:gw, can you comment to this bug?

Comment 5

[Glenn Watson [:gw]]

This seems to struggle even on a high-end ryzen system with a discrete radeon GPU (though it's not a particularly high-end GPU).

From a quick look at the page, the vertex, primitive, and glyph counts look low.

The render target count is high (21 targets per frame), but not so high that I'd expect it to cause that kind of slow down on my GPU.

However, the GPU profile counters show a very long time in each render target clear, draw and clip-mask creation. This makes me suspect that each of the render targets is really large.

It will need further investigation, but my guess is that we're not selecting an appropriate scale factor for the render targets, and drawing each of them at a huge size when they don't need to be.

Comment 6

[Gregory Pappas [:gregp]]

bug1749380 might have fixed this. The original Codepen link 404s, it is available on archive.org but the preview pane does not function. I found this fork with the same source code that does work. It is very laggy in v97 stable but seems fine in the latest Nightly (I think I see some hitching but it might be in my head).

Comment 7

[Glenn Watson [:gw]]

I confirmed the results from comment 6, thanks for checking - it's much faster in nightly. By enabling gfx.webrender.debug.render-targets, it's possible to see how many render targets and what size they are. In release version we allocate a lot more targets, and they are often 4k x 4k or even 8k x 8k. In nightly, we allocate fewer targets and they are all 2k x 2x or less, which makes sense given the observed performance differences.

Comment 8

[Mayank Bansal]

Agree with this resolution. The demo is quite smooth now.