Open
Bug 1422047
Opened 8 years ago
Updated 11 months ago
We rebuild the display list a lot while scrolling perspective trasnformed scroll frames
Categories
(Core :: Graphics: WebRender, enhancement, P3)
Core
Graphics: WebRender
Tracking
()
NEW
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.).
Comment 1•8 years ago
|
||
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.
Comment 2•8 years ago
|
||
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)
Comment 3•8 years ago
|
||
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.
Comment 4•8 years ago
|
||
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
Updated•8 years ago
|
Priority: -- → P2
Whiteboard: [gfx-noted][wr-mvp] [triage] → [wr-reserve] [gfx-noted]
Updated•8 years ago
|
Blocks: stage-wr-trains
Updated•8 years ago
|
Priority: P2 → P3
Reporter | ||
Updated•5 years ago
|
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
Reporter | ||
Updated•5 years ago
|
No longer blocks: stage-wr-next
Updated•3 years ago
|
Severity: normal → S3
Reporter | ||
Updated•1 year ago
|
Blocks: wr-displaylist-perf
You need to log in
before you can comment on or make changes to this bug.
Description
•