Scrolling long pages causes lots of display-list rebuilding and Janky scrolling on HiDPI 4K
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | wontfix |
People
(Reporter: val, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
Here's a profile while scrolling about:support:
https://profiler.firefox.com/public/105b6872a3375c9be82ab8fa1b05080f2baf1aa3/
— the amount of time spent in webrender_api::display_list::DisplayListBuilder::push_text
serializing the text is concerning..
Scrolling around the big wall of text in the Graphics section is noticeably janky, unlike the top and bottom portions of the page which are smooth.
gfx.webrender.debug.profiler
also shows that the scene is constantly rebuilt on scroll around that section, but not other places. Actually on other pages the rebuilds are happening right in the middle of the page too (??) but about:support is where the most jank happens.
The legacy GL layers compositor is perfectly smooth on the whole page.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
•
|
||
What's happening in the case of about:support is that gecko is invalidating the WR displaylist during scrolling when the intersection between the table and the displayport changes which happens continuously during scrolling with long tables when moving the displayport which happens at a fairly high frequency when scrolling is far enough from the top or bottom of the page that the display port isn't touching the top/bottom. This causes the scene to be re-built. If the scene contains a lot of text (most web pages do), push_text
will be visible in profiles.
The way I use the term "invalidation" is a bit handwavey here. What I should say is that the displayport is frequently updating which causes the DL and scene to be rebuilt continuously.
All of this DL and scene building probably eats up valuable CPU cycles and memory bandwidth (the latter being often a bottleneck with high res sreens) which is probably why you are seeing janky scrolling.
Actually on other pages the rebuilds are happening right in the middle of the page too (??)
This is normal. We build display-lists and scenes only for the content that intersects with the displayport. So as you scroll down a page we periodically ahve to move the displayport and update the display list and scene. It's fine but if it's happening continuously then it can be an issue.
Comment 2•4 years ago
|
||
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•4 years ago
|
||
The severity field is not set for this bug.
:jbonisteel, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Nightly should have a lot less scene building happening during scrolling now, is scrolling still janky for you towards the middle of about:support?
Reporter | ||
Comment 6•4 years ago
|
||
It's smooth!
The scene building time in the WR profiler still seems large (10ms on about:support, up to 20ms on more complex stuff like YouTube feed pages) but even 20ms is green in the graph (though red in the left pane) and even YouTube I can't call janky really so I guess that's okay.
Comment 7•4 years ago
|
||
Sweet! Scene building is known to be kind of slow, we have a long tail of performance improvements to make, but it is run asynchronously from scrolling which mitigates that to some extent.
I'll close this bug since we have other bugs on file for scene building performance and the bulk of the initial issue is addressed.
Updated•4 years ago
|
Description
•