1659000 - Judder while scrolling room list sidebar in Element

Status: NEW

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

Description

[Asif Youssuff]

Basic information

Steps to Reproduce:

1. Login to Mozilla's Matrix instance using Element
2. Scroll down list of chats/messages

Expected Results:

Smooth scrolling.

Actual Results:

Lots of judder.

---

More information

Profile URL: https://share.firefox.dev/2PQRG61

Basic systems configuration:

OS version: Windows 10

GPU model: Intel HD 600

Number of cores: 2

Amount of memory (RAM): 8GB

Thanks so much for your help.

Comment 1

[Asif Youssuff]

Attachment: about:support

Comment 2

[Markus Stange [:mstange]]

Can you capture another profile without screenshots?

Comment 3

[Asif Youssuff]

Profile without screenshots: https://share.firefox.dev/3kJR4gU

Comment 4

[Markus Stange [:mstange]]

Could you get another profile that also includes the SceneBuild threads?

I've filed bug 1659009 on one problem that I found, but it's not responsible for the judder.
Here's an example of a delay, focused in on a 73ms latency "APZScroll Payload Presented" marker: https://share.firefox.dev/2XZ9Qa8
The scroll update from its wheel event should be presented somewhere in the middle of the focused time window - there is a CompositeToTarget marker there, but the next composite on the renderer thread takes another 28ms before it starts. I'm not sure what causes that delay.
Also, if there's a smooth scroll animation running, we should be seeing consistent 60fps compositing, but there are big pauses on the renderer thread.

Comment 5

[Markus Stange [:mstange]]

Oh, and the RenderBackend thread.

Comment 6

[Asif Youssuff]

Profile with RenderBackend and SceneBuild: https://share.firefox.dev/31IRuLy

Comment 7

[Markus Stange [:mstange]]

Thanks!

Hmm... I can't make much sense of the profile.

Example: https://share.firefox.dev/30Zsu3T
It looks like the GPU process just isn't getting much CPU time during the scroll. You can see that there are large gaps between samples on the GPU process, at the beginning of each scroll gesture.
This is a machine with 2 cores. One core is probably busy executing main thread stuff. Not sure what the other core is busy with. It's not blob rasterization: According to the markers on the SceneBuilder threads, blob rasterization doesn't start until after the big gap.
If the profiler recorded which threads are taking up CPU time, it would probably be easier to understand what's going on.

Nical, this profile could be added to the list of evidence that the large number of thread hops in WebRender are probably hurting us.

Comment 8

[Asif Youssuff]

Markus, I am running Fission in this profile - any chance you'd be interested in one with Fission disabled?

Comment 9

[Markus Stange [:mstange]]

It's worth a try, sure - I don't expect it to add much insight, but it can't hurt to check.