1692828 - Scrolling lags due to long composites on mac

Status: RESOLVED DUPLICATE of bug 1734705

(Core :: Graphics: WebRender, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:87.0) Gecko/20100101 Firefox/87.0 ID:20210213095234

Sometimes I see lags when scrolling on TweetDeck. Here is an example:

https://share.firefox.dev/3de1PXf

As it can be seen composits can take up more then 30ms (some even show around 70ms). Most of the time seem to be spend in webrender::renderer::Renderer::render to render the frames.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Meanwhile this happens on various pages and not only TweetDeck. I can also see it on Bugzilla for long bugs, and within the profiler. Interestingly after some activities like starting the profiler the issue is gone for a moment or within a tab, but then comes back.

I have never seen that before and wonder if that might be a recent regression.

Comment 2

[Sotaro Ikeda [:sotaro]]

:mstange, can you comment to the bug?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Here another profile. Not sure if it's the same or not. But Firefox Nightly behaves kinda sluggish and that not only for scrolling but also when switching tabs. It feels like it takes up to 1s.

https://share.firefox.dev/3rTsAVc

As it looks like the Renderer thread is kinda busy, and long composites only occur at the very end of the recording. Nevertheless the function most of the time is spent in is the same as mentioned in comment 0.

Note that this issue comes and goes randomly. Didn't figure out yet how to reproduce.

Comment 4

[Markus Stange [:mstange]]

The time is spent waiting for the window server, I think. Or maybe for the GPU. It could be caused by having lots of windows open, system-wide. Or maybe we're leaking something. You could check the output of ioclasscount when it's good and when it's bad and see if there's a pattern, maybe... Or you could take an "all processes" profile with Instruments and see what's keeping the window server busy. Or you could take a Metal System Trace of Firefox with Instruments and see if there's something that's keeping the GPU busy.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Lets see what I can do when this happens again. Are there any special classes I should focus on for the ioclasscount command? It's a ton of output.

Comment 6

[Markus Stange [:mstange]]

yeah it's a lot :(
Maybe you can find a correlation by comparing a good case to a bad case.

Using Instruments probably has higher chances of success.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I haven't had the time to look closely yet, but I noticed an interesting case:

The sluggish behavior was noticeable on a Bugzilla page. So I tried to switch to Instruments to do a recording, but then noticed that at this time the Firefox Nightly update notification was displayed, and got opened a couple of seconds before. When I then closed the notification, everything was fine again. No lags in scrolling anymore.

I don't know how to trigger this notification and as such will wait once it opens again before doing more investigation. But maybe the above finding already helps to find the causing issue.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The update notification might have been a red herring. I noticed the problem yesterday again, and I tried to catch it in Instruments. But switching over to Instruments, starting the recording and coming back to Firefox immediately to perform some scrolling the lags weren't no longer reproducible. I'll keep observing the behavior.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Meanwhile I have seen this behavior a couple of times, mostly kinda random. And whenever it started to happen, and I switched to another application also Firefox was behaving correctly again afterward in all those cases. That means that I cannot use Instruments to record a profile and check what the WindowServer is doing.

Markus, do you have any suggestions?

Comment 10

[Holger]

If you explicitly make FF not the standard-browser, but let it check for this on startup, then you'll get a reproduceable and predictable notification.

The other idea would be, to load a page with embedded javascript for "alert('hello world')" ...

Comment 11

[Markus Stange [:mstange]]

In the profiles I can see the main thread spending time in CA::Transaction::observer_callback so I think this got fixed by bug 1690687 and bug 1734705.