Closed Bug 1634472 Opened 4 years ago Closed 4 years ago

Scrolling long pages causes lots of display-list rebuilding and Janky scrolling on HiDPI 4K

Categories

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

Desktop
FreeBSD
defect

Tracking

()

RESOLVED FIXED
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.

Flags: needinfo?(nical.bugzilla)
Priority: -- → P3
Severity: -- → normal

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.

Flags: needinfo?(nical.bugzilla)
Summary: [WebRender][Wayland] Janky scrolling on HiDPI 4K with lots of scene/display-list rebuilding → Scrolling long tables causes lots of display-list rebuilding and Janky scrolling on HiDPI 4K
Attached file without a table
Summary: Scrolling long tables causes lots of display-list rebuilding and Janky scrolling on HiDPI 4K → Scrolling long pages causes lots of display-list rebuilding and Janky scrolling on HiDPI 4K
Whiteboard: wr-planning
Depends on: 1635472

The severity field is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jbonisteel)
Severity: normal → S3
Flags: needinfo?(jbonisteel)
Whiteboard: wr-planning

Nightly should have a lot less scene building happening during scrolling now, is scrolling still janky for you towards the middle of about:support?

Flags: needinfo?(greg)

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.

Flags: needinfo?(greg)

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: