Scrolling on bugzilla.mozilla.org is not smooth
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox67 | --- | affected |
People
(Reporter: heftig, Assigned: gw)
References
(Blocks 2 open bugs)
Details
STR:
- Visit https://bugzilla.mozilla.org/show_bug.cgi?id=1530455
- Scroll down
Scrolling is not as smooth as on other pages.
Enabling picture-caching debugging shows the tiles are fixed to the viewport and don't scroll with the content.
Disabling the background on the <body> element (using style="background: none;") allows tiles to scroll but still repaints them constantly.
|
||
Comment 1•6 years ago
|
||
Note that bugzilla's page structure is such that it's not the root scroller that scrolls. Instead there's a scrollable div that does all the actual scrolling. So picture caching heuristics that try to detect the root scroller may not work.
|
Assignee | |
Updated•6 years ago
|
|
||
Comment 2•6 years ago
|
||
(In reply to Jan Alexander Steffens [:heftig] from comment #0)
Scrolling is not as smooth as on other pages.
What hardware do you see the slowness on?
|
Reporter | |
Comment 3•6 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
What hardware do you see the slowness on?
Linux, GNOME on Wayland, Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) (i7-6820HK) and a UHD screen.
Other sites like about:support and http://www.csszengarden.com/215/ appear to scroll smoothly.
Strangely, the profiler claims 60 fps. With layout.frame_rate = 0, it manages about 70 fps scrolling on Bugzilla, 80 fps on http://www.csszengarden.com/215/ and 120 fps on about:support.
I'm not sure if MOZ_ENABLE_WAYLAND makes it feel better or worse. Maybe a vsync issue is making exacerbating the problem?
|
|
Assignee | |
Comment 4•6 years ago
|
||
Notes from a quick look at the profiler:
(1) The vast majority of the GPU time is being spent in the gradient shader. There is a full-screen gradient background image. This is correctly identifying as opaque, but the current shader itself is really slow, especially when drawing a full 4k screen of pixels on integrated GPUs.
(2) There also appear to be some unexpected batching issues, where there are some solid background color fills that are running and filling the framebuffer before the full-screen gradient. This is wasted GPU time, since the gradient then completely overwrites these pixels.
(3) There are a total of 4 full-screen primitives drawn in the initial opaque pass - there are two additional primitives drawn after the initial background color + background gradient. It's not clear why these are needed yet, or what shader kind they are.
Profiling on my HD4600 at 4k on Linux:
- Combined, the four primitives above take up 14.6 ms.
- The total frame time is 19.4 ms.
- Those 4 primitives make up ~75% of the total frame time.
- Fixing those should get this page running well within frame budget.
For the gradient shader, there are several options:
- Make it work like the border shader (that is, cache to a surface, and draw as an image during the scene).
- Add a fast path gradient shader for common gradients (the existing gradient shader is slow because it handles an arbitrary number of color stops, which almost never happens).
For the batching, it seems likely to be a bug causing these items to overlap. If it's not a bug, we could consider a special shader path to combine multiple background rects / images / gradients in a single pass to reduce bandwidth requirements.
Note:
Optimizing the gradient shader has an additional benefit on every page we draw, since there are relatively expensive gradients drawn every frame in the main UI bars.
|
|
Assignee | |
Comment 5•6 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1533236 contains an optimization for simple gradients - this saves several ms of GPU time on this page. There's more ongoing work to resolve the other issues discussed above.
|
|
||
Comment 6•6 years ago
|
||
Is this still slow for you?
|
|
Reporter | |
Comment 7•6 years ago
|
||
Much improved! The picture caching issue is still there, but scrolling is smooth almost all the time.
|
|
||
Comment 8•6 years ago
|
||
Great. Let's mark this as fixed then.
Description
•