Open Bug 1422047 Opened 7 years ago Updated 24 days ago

We rebuild the display list a lot while scrolling perspective trasnformed scroll frames

Categories

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

enhancement

Tracking

()

Tracking Status
firefox59 --- affected

People

(Reporter: nical, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [wr-reserve] [gfx-noted])

While investigating bug 1415272 with the test case https://belen-albeza.github.io/scroll-demos/parallax.html I noticed that we rebuild the scene constantly during scrolling on that page (which is meant to show case APZ).
It's also the case on the github.com (the front page, not logged in).
On MDN we don't create new display lists constantly while scrolling but we'll create like 5 of them each time we stop.

In all of these sites it is the content process that is sending a lot of display lists (not something happening in the parent).

On some other sites like hacker news we don't have this issue.

perhaps on some of these sites there are js things reacting to scroll but it is worth checking.
Rebuilding display lists more than necessary exercises all of the most expensive code paths (buildign the DL, serialization/deserialization, building the scene, etc.).
On macOS, scrolling on github.com (front page, not logged in), I don't see any unexpected displaylist building. I used both the webrender profiler overlay and the display-list dumping and in both cases I only saw display list stuff happening when we scrolled enough to roll the displayport over to the next tile. Attaching screenshot - see how the left half of the DisplayList IPC just has single bars when the displayport rolled. The right side has more activity because it was repainting as I moved the mouse over stuff to get the screen capture taken.

Note that on this page by default the focus is in a textfield, so the cursor flashing on and off will cause repaints every 500ms. Also many of the things on the page have hover/mouseover effects so if you are moving the mouse around over items they will trigger repaints. But just scrolling shouldn't.
I also applied https://github.com/servo/webrender/pull/2141 and turned it on and got the same result - the epoch only increments when the displayport rolls over or something else is obviously causing a repaint (caret in textfield, mouseover etc)
On the https://belen-albeza.github.io/scroll-demos/parallax.html page I *do* see continuous repainting during scrolling. I'll take a look at why that is.
So if the scrollframe has perspective we always do the main-thread repaint because we don't actually properly support async-scrolling perspective things. The code is at [1] and it's waiting on bug 1254260 to be fixed (not sure what the latest status is on that, if there's an update not recorded in the bug).

[1] https://searchfox.org/mozilla-central/rev/be78e6ea9b10b1f5b2b3b013f01d86e1062abb2b/layout/generic/nsGfxScrollFrame.cpp#2888
Priority: -- → P2
Whiteboard: [gfx-noted][wr-mvp] [triage] → [wr-reserve] [gfx-noted]
This seems to be working well enough to ship.
Blocks: stage-wr-next
No longer blocks: stage-wr-trains
Summary: We rebuild the display list a lot while scrolling on some sites. → We rebuild the display list a lot while scrolling perspective trasnformed scroll frames
No longer blocks: stage-wr-next
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.