Open Bug 1451112 Opened 2 years ago Updated 12 days ago

Scrolling of specific website very slow with WebRender enabled (http://www.pcgameshardware.de)

Categories

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

61 Branch
defect

Tracking

()

People

(Reporter: linuxhippy, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180403100105

Steps to reproduce:

1. Loaded:  http://www.pcgameshardware.de/Notebook_Laptop-Hardware-201330/Specials/Ryzen-Mobile-im-Vergleich-1252536/#a3
2. Scrolled down a bit


Actual results:

When reaching the "blurred" content (paywall), scrolling starts to become choppy with WebRender enabled - while with the default OpenGL compositor it works well.

However, I wasn't really able to spot the issue in the profile: https://perfht.ml/2GR7XVS
The firefox-bin process consumes 100% cpu, while the GPU profiler shows the GPU is basically idle.
Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
some more details about the system: AMD Kaveri 7650k APU, Mesa-17.3.6, Linux-4.15.14
From the profile it looks like the blob image rendering is blocking the render backend thread, which then blocks APZ hit-testing, which in turn blocks the compositor thread. APZ assumes the RB thread is going to be responsive, so from my point of view the blocking on expensive blob image operations is bad.
This might actually become a serious problem - Jeff, do we have plans to make blob image rendering not block the render backend thread? If not, and if we can't guarantee a responsive RB thread, then maybe we should go back to using gecko hit-testing rather than using WR hit-testing. Or find a way to do WR hit-testing without blocking on the RB thread.
Flags: needinfo?(jmuizelaar)
We do have plans to make blob image rendering not block the render backend. See the just filed bug 1455422.
Flags: needinfo?(jmuizelaar)
Depends on: 1455427
Also for the record, I can repro this, and it happens even with async scene building enabled.
Status: UNCONFIRMED → NEW
Ever confirmed: true
For me this is "better" now in that we don't jank so much, but checkerboard instead. Will leave this open for now since we can probably still improve the perf here.

https://perfht.ml/2O7SzFb
Summary: Scrolling of specific website very slow with WebRender enabled → Scrolling of specific website very slow with WebRender enabled (http://www.pcgameshardware.de)
Runs well enough on Nvidia hardware
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Indeed a lot better compared to when I reported it.
Runs well here on an AMD APU on Linux using the RadeonSI driver, too.
Blocks: wr-perf
No longer blocks: stage-wr-next
See Also: → gfx-work
You need to log in before you can comment on or make changes to this bug.