Closed Bug 1455759 Opened 3 years ago Closed 3 years ago

Delayed scroll start with async scene building

Categories

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

enhancement

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox61 --- disabled

People

(Reporter: mstange, Assigned: kats)

References

(Blocks 1 open bug)

Details

Today I've been noticing delayed scrolling: Every now and then, a scroll gesture won't have any effects during its first 400ms (confirmed in the profiler), and then it starts.

It feels like we're waiting for apz.content_response_timeout even though the main thread is completely idle.
If you can get a profile that includes the WRRenderBackend and WRSceneBuilder threads it would be useful.
Blocks: 1391318, 1455591
Here's a profile: https://perfht.ml/2qUvb3m
You can see the "wheel" DOMEvent markers on the content thread which fired during the time where I was scrolling on my touchpad but nothing happened on the screen. Then at some point the screen starts updating, during the rest of the same pan gesture.
In this profile the delay seems to have been only 300ms, even though apz.content_response_timeout is 400, so the delay might not have anything to do with the timeout.

This happened on https://www.rust-lang.org/pdfs/Rust-Chucklefish-Whitepaper.pdf .
And another profile with a delay of 400ms: https://perfht.ml/2qUxbse
This seems really weird, I don't know what's going on. In theory the content response information might get stuck behind a long scene build but the profile shows the scene build as basically idle so that shouldn't be a problem. Maybe we're somehow discarding a scene in WR so we don't get the latest "built scene" epochs on the C++ side and so the content response information gets stuck in the queue until a subsequent successful scene build. But I'm pretty sure I checked that there's no codepaths like that.
Still not sure what's causing this, but while instrumenting the code and trying to reproduce I found a couple of optimizations that might help. Bug 1456561 is one, and https://github.com/servo/webrender/pull/2688 is another.
Assignee: nobody → bugmail
I replaced servo/webrender#2688 with servo/webrender#2703. Let's see if this still happens after that gets merged (and the rest of the inflight patches also land).
This stopped happening about two or three days ago. I don't have reliable STR unfortunately so I can't get a fix range.
Ok, it might have been fixed by the WR update.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.