1720263 - Increased suttering in Firefox 90 when using multiple monitors with WEBRENDER_DCOMP_PRESENT disabled (=Nvidia default)

Status: NEW

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

Description

[lpy750]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Have two monitors connected such as 144Hz & 60Hz. Visit this webpage, and move mouse on either monitor: https://www.testufo.com/photo#photo=alien-invasion.png&pps=960&pursuit=0&height=0

Actual results:

Visible stutter.

Expected results:

A reddit thread created here with some discussion: https://www.reddit.com/r/firefox/comments/oiqgjp/firefox_90_a_stuttering_mess_when_using_multiple/

Basically a regression with Firefox 90 vs Firefox 89, although neither are a pleasant smooth experience.

As discussed there, using a 144Hz monitor and 60Hz monitor disables WEBRENDER_COMPOSITOR which, in Firefox 89, caused some stuttering in Firefox if there was movement/activity on the second monitor. Now in Firefox 90, there is extreme stutter just by moving the mouse, on either monitor.

[WEBRENDER_DCOMP_PRESENT]
[blocked by env: Monitor refresh rate too high/mixed]

Using a program called mozregression narrowed it down to this being the cause of this: https://phabricator.services.mozilla.com/D112831

I'm guessing the above link (Bug 1706488) might not be an issue for single-monitor configurations, but WEBRENDER_DCOMP_PRESENT being blocked is now extremely stuttery and noticeable on a high refresh rate monitor, and as mentioned is now even worse with Firefox 90 release.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1706488

Comment 3

[Glenn Watson [:gw]]

Could you post the output of your about:support when you have your environment set up in a way that reproduces the major stuttering?

Comment 4

[lpy750]

Attachment: about:support

about:support explains that: DirectComposition blocked because of high/mixed monitor refresh rates (if I run a single-monitor setup, it's fine, but of course, I dont't want to do that). But now that it's worse in Firefox 90, I've started using Nightly (which I'm usually reluctant to do as it always has its own annoying bugs).

I'd use Firefox release if there was a way to force enable this (gfx.webrender.compositor.force-enabled doesn't work in this case), and I'm guessing this type of monitor configuration represents just a small percentage of users, but for me it's still an issue.

This is about:support created from a fresh profile (I've edited only the Windows account username).

Comment 5

[lpy750]

about:support explains that: DirectComposition blocked because of high/mixed monitor refresh rates (if I run a single-monitor setup, it's fine, but of course, I dont't want to do that). But now that it's worse in Firefox 90, I've started using Nightly (which I'm usually reluctant to do as it always has its own annoying bugs).

I'd use Firefox release if there was a way to force enable this (gfx.webrender.compositor.force-enabled doesn't work in this case), and I'm guessing this type of monitor configuration represents just a small percentage of users, but for me it's still an issue.

This is about:support created from a fresh profile (I've edited only the Windows account username).

Comment 6

[Glenn Watson [:gw]]

Thanks for posting the about:support.

I don't have that specific hardware to test with (neither the nvidia GPU, nor the high refresh rate monitor), but I think we can safely say that your GPU should have no problem running two monitors at that resolution without performance issues.

Jeff, Sotaro, any ideas who could look into this or what the cause might be? Is it related to our general issues with mixed frame rates?

lpy50, would it be possible to post a screen recording showing how bad the stuttering is?

Comment 7

[Glenn Watson [:gw]]

Sounds like jgilbert has a similar hardware setup and will try to repro locally.

Comment 8

[lpy750]

This is two mp4 files zipped. They are at 120 FPS so you might need a monitor capable of 120Hz to view properly. Firefox 90 vs Nightly 92. Nightly is fine because WEBRENDER_COMPOSITOR is available/enabled by default, hence unaffected/unrestricted by my monitor config.

https://we.tl/t-9U9wz8414p

Comment 9

[Kelsey Gilbert [:jgilbert]]

92nightly seems fine for:

Display0 3840x2160@60Hz : NVIDIA GeForce RTX 3070
Display1 1920x1080@120Hz : NVIDIA GeForce RTX 3070

Comment 10

[Kelsey Gilbert [:jgilbert]]

In 90.0release I do see:

WEBRENDER_DCOMP_PRESENT
available by default
blocked by env: Monitor refresh rate too high/mixed

...which I don't see in 92.

Comment 11

[Kelsey Gilbert [:jgilbert]]

So the difference is pretty explicit: https://searchfox.org/mozilla-central/rev/77f0b36028b2368e342c982ea47609040b399d89/gfx/config/gfxConfigManager.cpp#380

  if (!mIsNightly) {
    // Disable DirectComposition for NVIDIA users with high/mixed refresh rate
    // monitors due to rendering artifacts.
    nsAutoString adapterVendorID;
    mGfxInfo->GetAdapterVendorID(adapterVendorID);
    if (adapterVendorID == u"0x10de") {
      bool mixed = false;
      int32_t maxRefreshRate = mGfxInfo->GetMaxRefreshRate(&mixed);
      if (maxRefreshRate > 60 && mixed) {
        mFeatureWrDComp->Disable(FeatureStatus::Blocked,
                                 "Monitor refresh rate too high/mixed",
                                 "NVIDIA_REFRESH_RATE_MIXED"_ns);
      }
    }
  }

Comment 12

[Darkspirit]

As discussed there, using a 144Hz monitor and 60Hz monitor disables WEBRENDER_COMPOSITOR which, in Firefox 89, caused some stuttering in Firefox if there was movement/activity on the second monitor. Now in Firefox 90, there is extreme stutter just by moving the mouse, on either monitor.

But now that it's worse in Firefox 90,

1. The reported bug: Firefox Stable has become worse for your "Nvidia mixed refresh rates, therefore no DirectComposition" setup.

I've started using Nightly (which I'm usually reluctant to do as it always has its own annoying bugs).

2. Therefore you have started using Nightly because it allows you to use the better performing Direct Composition, but you might see bug 1638709 which is the reason Direct Composition is blocked for your setup on Beta/Stable.

Mozregression downloads Nightly builds which should have WEBRENDER_DCOMP_PRESENT and WEBRENDER_COMPOSITOR enabled by default, so you might have run into bug 1638709 and not tested the configuration of Firefox Stable.
If you want to use Mozregression to actually find out what made Firefox Stable worse, you need to set the preference gfx.webrender.dcomp-win.enabled to false in Mozregression.

Comment 13

[lpy750]

Ok I understand now.

And yes, using Mozregression, I had to manually set gfx.webrender.dcomp-win.enabled to false each time it downloaded a different build.

I am somewhat able to reproduce this, but not under the same circumstances as the other videos demonstrate. I'm not getting artifacts at all simply by just scrolling.

For me to be able to reproduce, there has to be two videos playing, one on each monitor, and the video resolutions have to match, eg. 1080p, 720p, etc. It's all very odd and specific. And I'm only seeing the artifacts within the video player itself, not on random parts of the screen.

So for example:
(monitor #1 = 144Hz, monitor #2 = 60Hz):
(video = a video playing on either YouTube or Twitch)

Video on monitor #1 @ 1080p + Video on monitor #2 @ 1080p = artifacts
Video on monitor #1 @ 720p + Video on monitor #2 @ 720p = artifacts
Video on monitor #1 @ 1080p + Video on monitor #2 @ 720p = no artifacts
Video on monitor #1 @ 720p + Video on monitor #2 @ 1080p = no artifacts

I also have the second monitor overclocked to 78Hz which would explain why it hasn't really affected me:

144Hz & 60Hz - artifacts
144Hz & 78Hz - no artifacts
165Hz & 60Hz - artifacts
165Hz & 78Hz - minor artifacts
248Hz & 78Hz - artifacts

As you can see, all very specific circumstances for this to occur. It does still exist, but basically a non-issue for me. Why it can't be easily reproduced as the uploaded videos from other users show, I can't explain that. Maybe things have changed with Firefox and/or Nvidia drivers that have almost, but not quite, eliminated it?

It would interesting to see if the people who originally reported this can reproduce it these days, or if, like my testing, the planets have to align so to speak.

Overall I'm not suggesting the compositor should be re-enabled for all Nvidia users again, as there is obviously still something going wrong, but if having it enabled is an overall better experience for my case, and basically a non-issue, what's the solution?

Comment 14

[Darkspirit]

(In reply to lpy750 from comment #13)

And yes, using Mozregression, I had to manually set gfx.webrender.dcomp-win.enabled to false each time it downloaded a different build.

That's too late. The pref must be set before Firefox starts otherwise its change won't have an effect. You can set a custom preference on the second page in Mozregression: https://youtu.be/IwrWot3jVFI?t=137
At the moment it seems like you have found a performance regression of WEBRENDER_COMPOSITOR (which uses the OS compositor instead of WebRender's internal draw compositor), but not the performance regression of Firefox Stable.
It would be good to be sure if the regression range you have found is for gfx.webrender.dcomp-win.enabled=false or true. Both configurations might have a performance regression with the same or different cause.

Since Firefox 90 there is another bug: With gfx.webrender.dcomp-win.enabled=false (restart required after changing the pref) you should normally not see any artifacts (bug 1638709 should only occur with true), but it is currently affected by bug 1712969 comment 5.

Comment 15

[lpy750]

Attachment: compositor_false.mp4

Thank you for letting me know. It was the first time I had used Mozregression, so my eyes skipped that option. I did it the hard way of going into the Temp folder, opening Firefox, setting the pref, and then restarting. I tried it again just now but this time using the correct method of setting custom pref on the second page. The result is the same: https://phabricator.services.mozilla.com/D112831

Extreme stuttering even when there is no activity/mouse movement on the second monitor (Firefox 90) vs little to no suttering when there is no activity/mouse movement on the second monitor (Firefox 89).

As for bug 1712969 comment 5 I am able to reproduce that. It's not flickering however, but there is something wrong. Videos attached (I think).

For now it would be handy if there was a pref to completely override https://searchfox.org/mozilla-central/rev/77f0b36028b2368e342c982ea47609040b399d89/gfx/config/gfxConfigManager.cpp#380 if a user chooses to do so, but that is of course a dev decision if something like that is to exist in Release, or only Nightly.

Comment 16

[lpy750]

Attachment: compositor_true.mp4

Comment 17

[Jeff Muizelaar [:jrmuizel]]

Aleino, here's another multi-refresh rate problem. Is it possible for Nvidia to look at reproducing and hopefully fixing this?

Comment 18

[aleino]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #17)

Aleino, here's another multi-refresh rate problem. Is it possible for Nvidia to look at reproducing and hopefully fixing this?

Is this a good summary?

Firefox: Firefox 90 with WEBRENDER_DCOMP_PRESENT disabled.
GPU: NVIDIA GeForce RTX 3080 (Vendor ID: 0x10de, Device ID: 0x2206)
Driver Version: 471.11
Monitor setup: One 144 Hz, one 60Hz
Procedure: Visit [1], and move mouse on either monitor. Example videos show stuttering when compositor is disabled: compositor_false.mp4, [2].

[1] https://www.testufo.com/photo#photo=alien-invasion.png&pps=960&pursuit=0&height=0
[2] https://bugzilla.mozilla.org/attachment.cgi?id=9231575

Comment 19

[Jeff Muizelaar [:jrmuizel]]

I believe so yes.

Comment 20

[aleino]

What code path happens when WEBRENDER_DCOMP_PRESENT is disabled?
Has anyone at Mozilla reproduced or profiled this?

Comment 21

[aleino]

(In reply to aleino from comment #20)

What code path happens when WEBRENDER_DCOMP_PRESENT is disabled?
Has anyone at Mozilla reproduced or profiled this?

By "code path" I mean, what is the method of composition if DirectComposition is not used?

Comment 22

[Jeff Muizelaar [:jrmuizel]]

aleino, I missed your message. When WEBRENDER_DCOMP_PRESENT is disabled we use normal D3D11 swapchain for presentation. This has worse performance then using DirectComposition.

DIrectComposition is disabled on Nvidia hardware because of bug 1642269. Do you have any updates on reproducing or fixing that one?

Comment 23

[Jim Mathies [:jimm]]

We believe this is fixed in the latest Win11 insider builds.

Comment 24

[lpy750]

That sounds like good news.

I'm using the latest Windows 11 stable build as of time of writing (22000.376) and I can't reproduce it. Does this mean it has made it to stable? Would be awesome to see if anyone else can confirm, and therefore hopefully get an exception in Firefox stable build for Windows 11 users if so.

Booting into my (old) Windows 10 SSD, I can still easily reproduce it, but no longer in Windows 11 using the same test method as mentioned.

Windows 11 (22000.376)
RTX 3080 using Nvidia driver 497.09
Firefox Nightly (97.0a1)

Comment 25

[lpy750]

Disregard that previous post.

I did reproduce it in Windows 11. Seems a little more stubborn for some reason but the bug does still exist.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 27

[lpy750]

Any future option planned while this bug exists to at least force enable WEBRENDER_DCOMP_PRESENT in about:config or similar if the user desires ?

This still annoys me on a daily basis without silly workarounds such as disabling other monitors before launching Firefox.

If I have one monitor running at 144Hz and another at 60Hz, the flickering is there, as expected. However, I run one monitor at 144Hz and the other at 76Hz, and there is no flickering, yet WEBRENDER_DCOMP_PRESENT is still blocked, hence my question above.

Comment 28

[xii_yuki]

Issue occurs for me.

• Winver: 19045.3208
• Firefox 120.0b9
• GPU: Nvidia GeForce RTX 2080 Ti
• Driver: 536.40
• 1 display: 1920x1080@165Hz
• 2 display: 1920x1080@60Hz
• 3 display: 1366x768@60Hz

Scenario: Anything that updates on 2nd or 3rd display causes Firefox (on 1st display) to stutter. Any constant movement on 2nd or 3rd display essentially makes Firefox (on 1st display) look like 60 fps. For reference: Chromium doesn't experience such behavior

Changing flags related to gfx.webrender makes no changes in behavior.

It seems that I can't post a file (about:support info), but this is present in about:support:

WEBRENDER_COMPOSITOR
default available
user disabled Disabled via gfx.webrender.compositor Blocklisted; failure code FEATURE_FAILURE_PREF_OFF
runtime unavailable No DirectComposition usage Blocklisted; failure code NVIDIA_REFRESH_RATE_MIXED

WEBRENDER_DCOMP_PRESENT
default available
env blocked Monitor refresh rate too high/mixed Blocklisted; failure code NVIDIA_REFRESH_RATE_MIXED

Comment 29

[lpy750]

(In reply to xii_yuki from comment #28)

Issue occurs for me.

For what it's worth, with a fairly recent Firefox release, they altered the code, and "Monitor refresh rate too high/mixed" no longer affects me, which means I no longer have any stuttering. It could be because I'm using Windows 11, and the blocklist still applies to Windows 10, if you can make sense of the code on this page: https://searchfox.org/mozilla-central/source/gfx/config/gfxConfigManager.cpp

Slightly off topic: wanting to remain on Windows 10 and not upgrade to Windows 11 is perfectly understandable to me.