Closed Bug 1692828 Opened 3 years ago Closed 10 months ago

Scrolling lags due to long composites on mac


(Core :: Graphics: WebRender, defect)

Firefox 87



Performance Impact low
Tracking Status
firefox87 --- affected


(Reporter: whimboo, Unassigned)


(Blocks 1 open bug)


(Keywords: perf, perf:responsiveness)

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:

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.

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.

Summary: Sometimes scrolling lags (due to long composits) on → Scrolling lags due to long composits
Summary: Scrolling lags due to long composits → Scrolling lags due to long composites
Blocks: wr-perf
OS: Unspecified → macOS

:mstange, can you comment to the bug?

Flags: needinfo?(mstange.moz)

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.

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.

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.

Flags: needinfo?(mstange.moz)
Severity: -- → S3
See Also: → 1684482

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.

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.

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.

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.

Whiteboard: [qf] → [qf:p3:responsiveness]

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?

Flags: needinfo?(mstange.moz)
Summary: Scrolling lags due to long composites → Scrolling lags due to long composites on mac

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')" ...

Blocks: wr-mac-perf
No longer blocks: wr-perf
Performance Impact: --- → P3
Whiteboard: [qf:p3:responsiveness]

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.

Closed: 10 months ago
Duplicate of bug: 1734705
Flags: needinfo?(mstange.moz)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.