1682135 - Low frame and late response for hamburger menu from Linux Firefox 85 with 125% fractional scaling (waiting on the window server)

Status: RESOLVED WORKSFORME

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

Description

[Taegeon Lee]

video link: https://photos.app.goo.gl/GeuskAj8ekR2yBbF8
youtube link: https://youtu.be/08d0HJI6WCI

Step to produce:

1. click hamburger menu button.
2. move and click any button on the menu.

Result: low frame and late response on the menu.

Expected result: fast response on the menu.

Comment 1

[:Gijs (he/him)]

That looks terrible. Unfortunately I cannot reproduce.

Is this a PPA build, or a mozilla.org one? If the former, can you reproduce with a mozilla.org one?

Does this affect any other menu UI (e.g. the library button) ? Do you know whether this regressed recently on nightly? Are you able to determine when that happened with e.g. mozregression ?

Alternatively, can you try gathering a performance profile using the Firefox profiler on https://profiler.firefox.com/ ?

Comment 2

[Taegeon Lee]

I am using firefox nightly PPA build and installed asan nightly build from https://firefox-source-docs.mozilla.org/tools/sanitizer/asan_nightly.html .
Both builds reproduce the regression. However, firefox beta(84) and release (83) do not reproduce.

In addition to the hamburger menu, the download menu and library menu occured the same regression.

Unfortunately, I installed ubuntu 21.04 two days ago. I cannot track when the regression occurred.

Comment 3

[:Gijs (he/him)]

(In reply to Taegeon Lee from comment #2)

I am using firefox nightly PPA build and installed asan nightly build from https://firefox-source-docs.mozilla.org/tools/sanitizer/asan_nightly.html .
Both builds reproduce the regression. However, firefox beta(84) and release (83) do not reproduce.

In addition to the hamburger menu, the download menu and library menu occured the same regression.

Unfortunately, I installed ubuntu 21.04 two days ago. I cannot track when the regression occurred.

OK, would it be possible for you to get a performance profile of the slowness to at least get some idea of what is at fault? Otherwise, without being able to reproduce, it's going to be difficult to make any progress here...

Comment 4

[Simona Badau, Desktop QA]

I tried to reproduce this issue, on Nightly PPA build and on an ASan Nightly build on Ubuntu 20.04 x64, but with no success.

Taegeon Lee, just to make sure that I understand correctly, are you saying that after the update to Ubuntu 21.04 you are no longer able to reproduce this issue?

Comment 5

[Taegeon Lee]

youtube: https://youtu.be/BLl5_mp6QQ0

I just totally reinstalled ubuntu 21.04.
I have not stayed the previous version.
It does not reproduce with updating nvidia driver by using Sudo ubuntu-drivers autoinstall and other packages by setting hiresure-proposed.
However, it reproduce when I change fractional display setting to 125%.

Can you advice how to make performance profile on Firefox?

Comment 6

[Taegeon Lee]

I remove Nvidia graphic driver by using sudo apt remove --purge '^nvidia-.*'

It reproduces with 125% Fractional scaling setting.

edit: only maximizing a window reproduces it.

Comment 7

[Taegeon Lee]

Attachment: Firefox information

Comment 8

[Taegeon Lee]

Attachment: Firefox info

Comment 9

[Simona Badau, Desktop QA]

I was able to reproduce this issue on Ubuntu 20.04 x64 and the latest Nightly 86.0a1 if I set the display to a scale of 125%. I'm currently trying to find a regression range, manually, since the issue does not reproduce on the mozregression builds.

I do not reproduce the issue when webrender is off (gfx.webrender.force-disabled = true).

Comment 10

[Jamie Nicol [:jnicol]]

I can see in the about:support page that your firefox is using the software webrender backend. Could you please go to about:config, and set gfx.webrender.all to true, and make sure that gfx.webrender.software is false. Then restart, and see if that helps. That will switch you to using the GPU backend rather than the software one.

A performance profile of it being slow would be really helpful to us. If you could reset the about:config preferences to how they were and restart, so that it is slow again. Then go to profiler.firefox.com and follow the instructions to capture a profile, then share the profile here. That would be much appreciated. Thanks!

Comment 11

[Taegeon Lee]

According to the Firefox info, I did not enable software webrender while it reproduced.
Surprisingly, enabling gfx.webrender.software solved the issus.

Comment 12

[Simona Badau, Desktop QA]

This doesn't appear to be a recent regression, If I'm enabling WebRender by setting the preference "gfx.webrender.all"=true I can reproduce it also on older Firefox versions. Firefox 80 is the older version I could reproduce it on (on my machine I get an unresponsive Firefox If I go any further).

I also tried to catch a performance profile, Nightly crashed several times on attempting to use the profiler. Here is the crash and the profile.

https://share.firefox.dev/37q8VES

https://crash-stats.mozilla.org/report/index/0c41a701-871d-41b6-a9ed-68db60201216

Comment 13

[Taegeon Lee]

I also crashed Firefox nightly with recording profiler when I clicked hamberger menu.
I shareed profiler from PPA nightly build.
https://share.firefox.dev/387vGN3
https://share.firefox.dev/3ajhAei

Comment 14

[Jamie Nicol [:jnicol]]

The crash while profiling appears to be whilst taking screenshots. You can disable this profiler feature by clicking on the toolbar popup menu, and changing the settings to "Firefox Graphics".

Taegeon, unfortunately because your Firefox is installed from the PPA instead of the official Mozilla build, the profile's symbols aren't correct. It's okay though, I can still work out what is going on from the libGLX symbols.

It looks like there's contention in the graphics driver due to rendering to multiple windows. I believe we have seen this before on Linux. It makes sense that software webrender "fixes" it, because we no longer use the graphics driver! What I'm not sure about is why the 125% scaling is important, nor how to properly fix the issue.

Specifically in those profiles we appear to be spending a lot of time querying the buffer age. My guess would be that the buffer age just happens to be the first thing in a frame, rather than it actually being the problem itself. Could you set the pref gfx.webrender.allow-partial-present-buffer-age to false, restart, and see if that helps? (and grab a couple more profiles)?

Additionally, could you try running firefox with the environment variable MOZ_X11_EGL=1 set, and see if that helps? Thanks.

Comment 15

[Simona Badau, Desktop QA]

(In reply to Jamie Nicol [:jnicol] from comment #14)

Specifically in those profiles we appear to be spending a lot of time querying the buffer age. My guess would be that the buffer age just happens to be the first thing in a frame, rather than it actually being the problem itself. Could you set the pref gfx.webrender.allow-partial-present-buffer-age to false, restart, and see if that helps? (and grab a couple more profiles)?

Setting the preference gfx.webrender.allow-partial-present-buffer-age to false doesn't help. Here is the performance profile.
https://share.firefox.dev/3p1o6dH

Additionally, could you try running Firefox with the environment variable MOZ_X11_EGL=1 set, and see if that helps? Thanks.

It doesn't, the issue still occurs.

Comment 16

[Taegeon Lee]

I tried to change gfx.webrender.allow-partial-present-buffer-age to false on Firefox 86. However, the firefox occured the issue.

Comment 17

[Julien Cristau [:jcristau]]

Jamie is there something we need to do here for fx85?

Comment 18

[Jamie Nicol [:jnicol]]

I'm not sure I'm afraid. Andrew?

Comment 19

[Andrew Osmond [:aosmond] (he/him)]

On the renderer thread, we are blocking on waiting for a reply from the X server. Similarly, we seem to be spending a lot of time in getting the window origin in the parent process main thread:

https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/widget/gtk/nsWindow.cpp#396

Seems like this is related to the issue we tried fixing in bug 1635153 but had to back it out the fix. This does not necessarily shed light on why we regressed in 85 however...

Comment 20

[Andrew Osmond [:aosmond] (he/him)]

Do you think the vsync changes made in 85 could be related to this?

Comment 21

[Andrew Osmond [:aosmond] (he/him)]

Wait I see bug 1645528 got backed out of beta around the last time we tested. Taegeon, can you still reproduce in the latest 85 beta? It isn't clear to me from the bug if it was backed out of nightly / 86....

Comment 22

[Robert Mader [:rmader]]

(In reply to Andrew Osmond [:aosmond] from comment #21)

Wait I see bug 1645528 got backed out of beta around the last time we tested. Taegeon, can you still reproduce in the latest 85 beta? It isn't clear to me from the bug if it was backed out of nightly / 86....

It was only backed out of beta, not nightly.

(In reply to Andrew Osmond [:aosmond] from comment #20)

Do you think the vsync changes made in 85 could be related to this?

After the follow up in bug 1681030 X11 behaviour should be unchanged - so fresh testing might be in order :)

Comment 23

[Taegeon Lee]

I tested Firefox 85b5 and Firefox nightly by reinstalling from the Mozilla site.
Both still reproduce the issue.

Comment 24

[alkaline.coexist703]

I evidently subscribed to this ticket many years ago and I vaguely remember the problem. Got an email about it tonight with the activity and wanted to post that I am running the latest Firefox, on Wayland with 125% scaling and don't see this issue and probably haven't for a while since I guess I forgot about the issue. Might be some indication that it is no longer an issue.

Comment 25

[Glenn Watson [:gw]]

Thanks, we'll assume fixed - please reopen if still causing issues for others.