From https://www.reddit.com/r/firefox/comments/glfgm1/weird_artifact_issue/

I can't find any other reports of this but I think I might just have an unusual enough setup for it to not be widespread.

I have two monitors, one 1920x1080@60Hz and the other a 3440x1440@144Hz . If I have a Firefox window on each monitor and have video playing (Twitch or YouTube) on the 1920x1080 then I get artifacts in the other window especially when scrolling. If I change to another tab and have the video playing in the background the artifacts go away. The artifacts also don't seem to appear if I have the video on the 3440x1440 and scroll on the 1920x1080 monitor, and they don't show up in screenshots or when recording my screen.

I have tried with G-sync on and off just in case that was an issue but it happens with either. The artifacts also appear on sites that have CSS animations even if I don't scroll.

I am on Nightly 78.0a1 (2020-05-16) and this started happening a couple of weeks ago. I have tested with 76.0.1 and 77.0b6 and the issue appears in them too.

The computer is running Windows 10 Pro version 2004 build 19041.264 and has Intel Core i9-9900K, 32GB RAM, GeForce RTX 2080 SUPER

2020-05-17T18:32:00.780000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=cd2634c753b9b955aafc290d57f0cbcdf9fab688&full=1
2020-05-17T18:32:01.958000: DEBUG : Found commit message:
Bug 1592509 - Re-enable gfx.webrender.compositor by default on Windows r=gw,jrmuizel

Differential Revision: https://phabricator.services.mozilla.com/D59434

2020-05-17T18:32:01.958000: DEBUG : Did not find a branch, checking all integration branches
2020-05-17T18:32:01.958000: INFO : The bisection is done.
2020-05-17T18:32:01.959000: INFO : Stopped

I set gfx.webrender.compositor to false and can confirm this stops the artifacts from showing.

Is it possible to get a screenshot / recording of what the artifacts look like?

The user posted a video: https://streamable.com/mjj7mu

I wonder if this could be because of:

I have two monitors, one 1920x1080@60Hz and the other a 3440x1440@144Hz

We landed a patch last week to block on higher refresh rate monitors: https://bugzilla.mozilla.org/show_bug.cgi?id=1638011

I have been doing some more testing with this today (I am the original reporter) and it turns out I was incorrect in saying

The artifacts also don't seem to appear if I have the video on the 3440x1440 and scroll on the 1920x1080 monitor

they do show but less often and less consistently.

I have also tested the 3440x1440 monitor at different refresh rates and the issue only appears at 144hz. No artifacts show with it set to 60Hz, 75Hz, 100Hz, or 120Hz. It does look like the difference is refresh rates is what is causing this.

I know that MS has done some work recently on setups where the monitors have different refresh rates [1].

I don't know what Gecko does with different refresh rates, if anything at all.

The reported driver version from about:support is:

Driver Version: 26.21.14.4587
Driver Date: 4-3-2020

The article in [1] suggests that NVIDIA driver 450.12 contains changes to handle different refresh rates. I'm not sure how that correlates to the driver version above - is there any newer NVIDIA driver available for testing with?

Any other ideas Jeff, Sotaro? I think this is probably a driver issue, rather than something we're doing, but maybe there is some issue with how we synchronize / recycle resources when the refresh rate differs by that much?

[1] https://www.notebookcheck.net/Windows-10-2004-20H1-finally-gets-multi-monitor-refresh-rates-right.454143.0.html

Marking as S3 for it affecting only a specific refresh rate and GPU vendor.

I am on Windows Insider slow track so I am already running version 2004 with these changes. However my NVIDIA driver version is 445.87 which is the latest available right now, I can't seem to find 450.12 anywhere. Once 450.12 is released I'll upgrade and report back. I am not sure this is the issue though, after reading that article I ran the Blur Busters UFO motion test referenced and could not replicate the issue they mentioned.

I did a little more research into the driver versions.

It looks like the 450.x series are updated drivers for WDDM 2.7 (which is part of Win10 2004), but they are not released publicly yet. They're available as beta drivers on the NVIDIA developer site but only available if you have a developer account, so it seems they're not ready for release yet (it sounds like they'll be released once Win10 2004 hits public release).

I'll see if I can find out any more information from MS / NVIDIA about whether this is likely to be a driver bug / fix this issue.

(In reply to Glenn Watson [:gw] from comment #6)

Any other ideas Jeff, Sotaro? I think this is probably a driver issue, rather than something we're doing, but maybe there is some issue with how we synchronize / recycle resources when the refresh rate differs by that much?

It seems like a driver issue. With DC native compositor, Each IDCompositionTarget is related to each window. Rendering result should not be mixed.

https://searchfox.org/mozilla-central/rev/a40ef31fc9af34a99ceda6d65cdc4573d52b83d2/gfx/webrender_bindings/DCLayerTree.cpp#86

Hi Asif,

If you have time, please provide the following information:

• The interfaces on each of the displays. (HDMI/DP?)
• The display models.
• Links to some specific video that this has been shown to happen with.

(In reply to aleino from comment #11)

Hi Asif,

If you have time, please provide the following information:

• The interfaces on each of the displays. (HDMI/DP?)
• The display models.
• Links to some specific video that this has been shown to happen with.

I am the original reporter from the reddit post.

• Both displays are run over DisplayLink.
• The 60Hz is a Dell U2311H and the 144Hz is a LG 34GK950F
• I have seen it with pretty much any video but it looks like the higher the frame rate the more it happens. A good example is https://vimeo.com/246618509

I have been doing more testing this morning and think I may have uncovered something interesting. When I go to https://www.vsynctester.com/ with just the 60Hz display enabled then it correctly reports a 60Hz display and ~60fps. Similarly if I just have the 144Hz monitor enabled then it reports 144Hz and ~144fps. However with both displays enabled the site reports 144Hz and ~144fps when it is on either screen. Running the site in two windows, one on each screen, is also a great way to reproduce the bug.

Strangely if I have one Firefox window on the 144Hz display and then open https://www.vsynctester.com/ in Chrome on the other display then the artifacts show on the Firefox window. The artifacts also show in the preview of the Firefox window if I press Win+Tab and in the preview of the window if I drag a window to one side of the monitor (see https://streamable.com/fwf5ow)

I've filed internal Nvidia bug 2993601 to reproduce and investigate this.

Let's track this.

I have updated the NVIDIA driver to version 446.14 and am now on Fireforx Nightly 78.0a1 (2020-06-01) and the issue is still present. There's still no sign of the 450.12 driver for me yet.

Another user on reddit said they have experienced the same issue and I asked them for more information on their setup but am yet to hear back.

ni'ing myself to try repro (also try with DC off)

Can't repro on 2060 rtx, but I don't have a 144Hz screen.

Jason: Can you check if you can get the latest driver now. Locally I received 450.99, but I'm on the Windows Insider slow ring, so not sure if it's available for you.

Bug 1643260 might also related to Windows version 2004.

I can also reproduce this by simply opening nightly. I am on Windows 10 2004, with a RTX 2080 and driver verison 446.14, with dual monitors, running nightly. I currently have gfx.webrender.compositor set to false as a workaround. Disabling my second monitor or unplugging it also makes the issue go away.

(In reply to Kris Taeleman (:ktaeleman) from comment #17)

Can't repro on 2060 rtx, but I don't have a 144Hz screen.

Jason: Can you check if you can get the latest driver now. Locally I received 450.99, but I'm on the Windows Insider slow ring, so not sure if it's available for you.

Sorry for the slow response on this, I am still on 446.14 and there are no updates available for me right now. I am also on the Windows Inside slow ring, but I have my drivers installed through GeForce Experience. Not sure if that makes a difference.

I have the same setup (Insider slow ring + Geforce experience).
It seems nVidia is still experimenting with the 450 driver branch according to https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/379601/windows-10-may-2020-update-20h1-feedback-thread/ and the update should have come through windows update. My guess is that I'm just part of a different experiment group.

Driver version 451.48 just became available for the 2080 SUPER (and probably for other GPUs as well).
It can be found here https://www.nvidia.com/download/index.aspx?lang=en-us.

We have reason to believe that this should fix the issue.
Can you install NVIDIA driver 451.48 and see if that fixes the issue?

Oh, hold on.. Is Jason the only one who can repro this?

Jason, could you try out NVIDIA driver 451.48 and see if that fixes the issue?

Still seeing the issue with driver version 451.48 and Firefox Nightly 79.0a1 (2020-06-25) unfortunately. I have noticed it seems to be more intermittent and a lot less severe when the artifacts do appear over the last week or so, but definitely is still an issue.

Thanks Jason, I've forwarded the information to the internal Nvidia bug.
We'll try to reproduce it.

Jason, could you try reproducing with both "on" and "off" for the following value
Nvidia control panel -> 3D Settings -> Manage 3D settings -> Global settings -> Vertical sync
and then tell me the result for each one?

Jason, could you provide more information about your DisplayLink solution? The DisplayLink technology is not very familiar to me.
I assume you're referring to https://en.wikipedia.org/wiki/DisplayLink?

Also, would it be possible to try this without DisplayLink?

(In reply to aleino from comment #27)

Jason, could you try reproducing with both "on" and "off" for the following value
Nvidia control panel -> 3D Settings -> Manage 3D settings -> Global settings -> Vertical sync
and then tell me the result for each one?

I get the artifacts with both settings still.

(In reply to aleino from comment #28)

Jason, could you provide more information about your DisplayLink solution? The DisplayLink technology is not very familiar to me.
I assume you're referring to https://en.wikipedia.org/wiki/DisplayLink?

Also, would it be possible to try this without DisplayLink?

Sorry, that was a typo, I meant they are both running over displayport, not DisplayLink.

Do the newer 451.67 drivers help with this? Is HW-Accelerated GPU Scheduling enabled?

Adding a NI to see if the suggestions above help ^

I am still seeing the artifacts with 451.67. I tried with vsync on and off as well as HW-Accelerated GPU scheduling on and off. The results were the same.

(In reply to Arthur K. from comment #30)

Do the newer 451.67 drivers help with this? Is HW-Accelerated GPU Scheduling enabled?

I am still seeing the issue with the new drivers and HW-Accelerated GPU Scheduling enabled unfortunately.

(In reply to jason from comment #33)

(In reply to Arthur K. from comment #30)

Do the newer 451.67 drivers help with this? Is HW-Accelerated GPU Scheduling enabled?

I am still seeing the issue with the new drivers and HW-Accelerated GPU Scheduling enabled unfortunately.

Ok, I'd suggest trying these too (https://nvidia.custhelp.com/app/answers/detail/a_id/5046) but I am leaning for it to be FF fault. Did you also disable HW-Accelerated GPU Scheduling? probably not going to make a change but just to check all the boxes.

79.0 should be out tomorrow. Try with that version as well and do report back with all things enabled.

Just an update from my side:
There have been some repro attempts on Nvidia bug 2993601, but no successful repro yet.
Due to the ongoing pandemic, our testers don't have ready physical access to hardware.
The tester assigned to this bug is trying to reproduce over VNC, which I think is a likely reason that the attempts have not succeeded.

I'll poke the Nvidia bug again to see if there is any way to test this with a physical machine.
This might take a long time though, because access to physical machines is now a pretty scarce resource.

Jason:
If at all possible, it would be helpful to know if you are able to reproduce when running over VNC.
This is quite a long shot, though. It won't necessarily be worth the effort. As said, I think you would not see this issue over VNC.
It's just something that you could try if you have the time and interest for it.

I noticed this issue recently. It started happening after I plugged in a second display. 2560x1440 144hz gsync displayport main and 1920x1080 60hz hdmi secondary.

I have an nvidia gtx 1080. I have tried updating my drivers and disabling/enabling hardware acceleration. I haven't had any issues with webrender before windows 2004 update. i have tested with firefox 78 and 79

Is this the correct place to post my info? or is this bug post limited to the 2080 graphics card? Is there any other information that would be useful?

@aleino: Do you have an update on this from your end?

@ktaeleman: There have been some failed repro attempts on the corresponding nvidia bug (2993601), and the bug is marked as requiring more information. I'll see if I can help get it going again.

I'm also experiencing this, setup is primary monitor is 3440x1440@144hz (gsync displayport), 2 secondaires are 1200x1920@60hz (1 dp, 1 hdmi).
AMD Ryzen 7 3800X, Geforce 2080 SUPER, 32gb of memory, Windows 10 version 2004 (19041.508), Firefox 81.0.1

It will occur far more visibly if the firefox window touches a 60hz monitor at any given point.

If I can provide any sort of information to help, I would be glad to do so.

(In reply to alex from comment #39)

I'm also experiencing this, setup is primary monitor is 3440x1440@144hz (gsync displayport), 2 secondaires are 1200x1920@60hz (1 dp, 1 hdmi).
AMD Ryzen 7 3800X, Geforce 2080 SUPER, 32gb of memory, Windows 10 version 2004 (19041.508), Firefox 81.0.1

It will occur far more visibly if the firefox window touches a 60hz monitor at any given point.

If I can provide any sort of information to help, I would be glad to do so.

Thanks!
What driver version do you have?

If it's not too much trouble, please try with driver version 456.71.
Unfortunately our QA engineers have not been able to reproduce yet.

(In reply to aleino from comment #41)

If it's not too much trouble, please try with driver version 456.71.
Unfortunately our QA engineers have not been able to reproduce yet.

I am currently on 456.71, which I just did a clean reinstall of the drivers to ensure no profile crud is left over and could be the cause, and this is unfortunately still obervable :(

It happens mostly with heavy graphical pages such as grids of thumbnails and video. It is either not occuring or way less noticable on things such as the mozilla bugzilla.

Reproduction steps that work for me:

1. Launch firefox on primary monitor (3440x1440@144hz)
2. scroll page with graphical/video thumbnails (youtube and imgur are good candidates)
3. Move window accross monitor boundaries, onto secondary monitor (1200x1920@60hz)
4. Scroll page, visual glitching occurs with ghost tiles, just as in the previous videos
5. Move window back on primary monitor entirely, artifacting is less agressive, but if the window is in focus and the cursor crosses the screen boundary, it reoccurs.

(In reply to alex from comment #42)

(In reply to aleino from comment #41)

If it's not too much trouble, please try with driver version 456.71.
Unfortunately our QA engineers have not been able to reproduce yet.

I am currently on 456.71, which I just did a clean reinstall of the drivers to ensure no profile crud is left over and could be the cause, and this is unfortunately still obervable :(

It happens mostly with heavy graphical pages such as grids of thumbnails and video. It is either not occuring or way less noticable on things such as the mozilla bugzilla.

Reproduction steps that work for me:

1. Launch firefox on primary monitor (3440x1440@144hz)
2. scroll page with graphical/video thumbnails (youtube and imgur are good candidates)
3. Move window accross monitor boundaries, onto secondary monitor (1200x1920@60hz)
4. Scroll page, visual glitching occurs with ghost tiles, just as in the previous videos
5. Move window back on primary monitor entirely, artifacting is less agressive, but if the window is in focus and the cursor crosses the screen boundary, it reoccurs.

I think the handling of high refresh rate monitors has always been glitchy in Windows. Maybe other OSes in general. Not sure about Mac / Linux land. Windows 10 v2004 was supposed to greatly improve upon handling of multi-monitor setups mixing both high and low refresh rates (144Hz/60Hz). However, I'm not shocked this is still happening. With the Windows 10 20H2 update supposedly coming out in this Tuesday's update and Microsoft saying that all the bits for it are already on the machines of those with v2004---Tuesday's update will purportedly "flip it on", so to speak--I'm curious to see if there's any improvement.

If the above still holds true with tomorrow's update and you install it and later do a Winver and it shows 19042.5xx there, then you're on the new October 20H2 version. Perhaps try your STRs from Comment 42 and see if it's any better.

(In reply to Arthur K. from comment #43)

If the above still holds true with tomorrow's update and you install it and later do a Winver and it shows 19042.5xx there, then you're on the new October 20H2 version. Perhaps try your STRs from Comment 42 and see if it's any better.

I have applied today's cumulative update, winver does report a corresponding version. I have tried the repro steps on it and there has definitely been an improvement.

The artifacts will still show up when the window spans monitors of different refresh rates, but it will no longer persist to the same degree upon being returned to the 144hz monitor.

It still seems to happen very lightly, at the start of a scroll, but not nearly as egregiously as before. Large ghost tiles no longer show up during scroll. Had I not seen it prior, I would have written it off as some weird render quirk of whatever website I was browsing.

(In reply to alex from comment #44)

(In reply to Arthur K. from comment #43)

If the above still holds true with tomorrow's update and you install it and later do a Winver and it shows 19042.5xx there, then you're on the new October 20H2 version. Perhaps try your STRs from Comment 42 and see if it's any better.

I have applied today's cumulative update, winver does report a corresponding version. I have tried the repro steps on it and there has definitely been an improvement.

The artifacts will still show up when the window spans monitors of different refresh rates, but it will no longer persist to the same degree upon being returned to the 144hz monitor.

It still seems to happen very lightly, at the start of a scroll, but not nearly as egregiously as before. Large ghost tiles no longer show up during scroll. Had I not seen it prior, I would have written it off as some weird render quirk of whatever website I was browsing.

This is reassuring to hear but I noticed after updating, winver reports 19041.572. You're seeing the same? So it would seem this update was not part of the Win10 19042.5xx / 20H2 enablement. I can only assume these are the final OS bits before the pack is offered some time later this month. Everything I'm reading online now says it's coming toward the latter part of the month.

So, something I can confirm. Once installing the Enablement Pack from (KB4562830), winver will report 19042.572. However, it's not introducing anything new or fixing any bugs that might be in WDDM 2.7, it's just cosmetic and nags the new Chrome-based Edge. So, whatever came in this week's patch is as good as it's going to get for now.

(In reply to alex from comment #44)

(In reply to Arthur K. from comment #43)

If the above still holds true with tomorrow's update and you install it and later do a Winver and it shows 19042.5xx there, then you're on the new October 20H2 version. Perhaps try your STRs from Comment 42 and see if it's any better.

I have applied today's cumulative update, winver does report a corresponding version. I have tried the repro steps on it and there has definitely been an improvement.

The artifacts will still show up when the window spans monitors of different refresh rates, but it will no longer persist to the same degree upon being returned to the 144hz monitor.

It still seems to happen very lightly, at the start of a scroll, but not nearly as egregiously as before. Large ghost tiles no longer show up during scroll. Had I not seen it prior, I would have written it off as some weird render quirk of whatever website I was browsing.

Just curious about something. Regarding your primary monitor that can do 144Hz: I surmise it can also go all the way down to 60Hz as well? What happens when you drop refresh rate down to 60Hz and then try your STR? Still repros? What make and model is it?

(In reply to Arthur K. from comment #47)

Just curious about something. Regarding your primary monitor that can do 144Hz: I surmise it can also go all the way down to 60Hz as well? What happens when you drop refresh rate down to 60Hz and then try your STR? Still repros? What make and model is it?

It does support that, I changed the mode manually in the adapter settings to 3440x1440@60hz, and I am not getting any artifacts at all, when spanning monitors and when on the main monitor, pages scroll as they should, no visible artifacts.

The monitor is a LG 34GN850-B.

(In reply to alex from comment #48)

(In reply to Arthur K. from comment #47)

Just curious about something. Regarding your primary monitor that can do 144Hz: I surmise it can also go all the way down to 60Hz as well? What happens when you drop refresh rate down to 60Hz and then try your STR? Still repros? What make and model is it?

It does support that, I changed the mode manually in the adapter settings to 3440x1440@60hz, and I am not getting any artifacts at all, when spanning monitors and when on the main monitor, pages scroll as they should, no visible artifacts.

The monitor is a LG 34GN850-B.

Yep, that's what I thought was going to happen. Thanks for the info. So it seems while in a 144Hz/60Hz setup, either Windows or FF is not giving/getting....awareness?...to the FF session when it transitions from one refresh rate to the other and back again. Going from 60Hz to 60Hz makes sense that you see no issues. It's a fluid rate across the span. I'm not sure where the fault lies here but thanks for the additional testing.

(In reply to alex from comment #44)

The artifacts will still show up when the window spans monitors of different refresh rates, but it will no longer persist to the same degree upon being returned to the 144hz monitor.

(In reply to nasso from comment #50)

I'm having the same issue:

Barring any last minute issues, 82.0 will likely come out Tuesday. Can you test again after updating to 82.0 and see if things have improved any?

Does this repro in Chrome or others browsers as well? Comment 12 kind of tests in separate monitors but not dragging the Firefox window across different monitors.

Hi, I have some bonus information:

I was pondering the age of my current Windows 10 install and felt there might be long lived crud at play. So I did a Refresh (which is basically an in place clean install that drops most of %APPDATA% in your profile, alongside with everything else, but keeps your documents in place).
I had prior done a full clean install of the nvidia drivers, but that had not helped.

After reinstalling the platform and video drivers, I restored the firefox profile from a backup, installed 81.0.2, and now the artifacts are entirely gone. As far I can tell, nothing really changed on the firefox side. My repro steps just no longer repro.

The artifacts are still visible when a window spans a 144hz and 60hz desktop, but they no longer return at all when exclusively on the 144hz monitor.

What a maddening mystery.

(In reply to Arthur K. from comment #52)

Does this repro in Chrome or others browsers as well? Comment 12 kind of tests in separate monitors but not dragging the Firefox window across different monitors.

Prior to reinstalling a clean windows, I had given this a try to compare, Chome and latest Edge don't have the issue at all, either when on individual monitors or spanning them, accross different refresh rates.

I am afraid I spoke too soon: After a couple of reboots, the artifacting has showed up again. I will try 82.0 when it comes out and report.

(In reply to alex from comment #54)

I am afraid I spoke too soon: After a couple of reboots, the artifacting has showed up again. I will try 82.0 when it comes out and report.

So, this got me to thinking last night. For a bit there, you'd say it was tough to repro but eventually it came back, yes? I'm wondering if there was a missed opportunity here. The only thing different than before was you did an in-place refresh of windows rather than a in-place re-install. If you restored FF profile from backup, it would have had the same settings/config as before you refreshed Windows and is kind of making me lean more and more toward this being Windows still not quite getting apps to behave right between the two refresh rates. So is this some kind of caching Windows is doing? And you already tried with Graphics Settings > Hardware-Accel. GPU Settings both on and off, right?

But regarding artifacting coming back after the refresh, this is just FF or also with Edge and Chrome?

(In reply to alex from comment #48)

The monitor is a LG 34GN850-B.

And here's another longshot. Do you have the OEM driver installed for the monitor or, in Device Manager, does it just show Generic PNP Monitor for the LG? If Generic, could you for the heck of it try the driver for it from https://tinyurl.com/yxzxbudx ? Seems to have been updated recently so...maybe it'll help be less dumb?

Hello,

Upgraded Win 10 today from 1909 to 20H2 and started having this issue as well. Nothing similar ever happened before while using WebRender. Everything apart from the upgrade is exactly the same on this machine, so must be something to do with those new "multi monitor features".

FF 82.0
2560x1440@144Hz + 2560x1440@60Hz
1080 Ti on 456.98 drivers
HAGS on vs. off doesn't seem to make a difference.

Flickering seems to happen only on 144Hz screen while video is playing on 60Hz one, not the other way round.

(In reply to alex from comment #54)

I am afraid I spoke too soon: After a couple of reboots, the artifacting has showed up again. I will try 82.0 when it comes out and report.

Alex? Still the same issue with 82.0?

(In reply to Arthur K. from comment #59)

(In reply to alex from comment #54)

I am afraid I spoke too soon: After a couple of reboots, the artifacting has showed up again. I will try 82.0 when it comes out and report.

Alex? Still the same issue with 82.0?

I updated last night, unfortunately it still happens :(
To confirm, windows build is 20H2 (19042.572)

(In reply to Arthur K. from comment #56)

(In reply to alex from comment #48)

The monitor is a LG 34GN850-B.

And here's another longshot. Do you have the OEM driver installed for the monitor or, in Device Manager, does it just show Generic PNP Monitor for the LG? If Generic, could you for the heck of it try the driver for it from https://tinyurl.com/yxzxbudx ? Seems to have been updated recently so...maybe it'll help be less dumb?

Additionally, I tried this but all the driver contains (AFAICT) is a color profile. Problem is still reproductible with it

I landed a fix recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1672077) for an unrelated problem. However, the symptoms that bug could cause are possibly the same as what you're seeing in this case.

Are you able to test in a nightly (it should also be landed on the current beta) and just check if it is fixed or improved by that patch?

Hi recently this issue has started happening for me.
On all the latest drivers, have one 144hz monitor one 60hz monitor.
Artifacts only appear on the faster monitor. Gets worse if media is playing (in the background/foreground/other window)
I have FF 83.0b5
about-support: https://pastebin.com/nL88U3gE
This is an incredibly annoying bug. If any testing needs doing i'm willing to help in any way

(In reply to Glenn Watson [:gw] from comment #62)

I landed a fix recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1672077) for an unrelated problem. However, the symptoms that bug could cause are possibly the same as what you're seeing in this case.

Are you able to test in a nightly (it should also be landed on the current beta) and just check if it is fixed or improved by that patch?

I have tried to repro on the current nightly, which is listed as 84.0a1 (2020-10-29) (64-bit)
It unfortunately is immediately reproductible, even with a new empty profile :(

Same here on the latest Nightly.

Although I am not optimistic, I noticed this in the release notes of the newly minter 457.09 drivers:

"Random flicker may occur in multi-monitor configurations when G-SYNC is enabled. Flickering occurs on Dell S2417DG and Dell S2716DG monitors when playing YouTube or Twitch videos at 144 Hz. [3147515]"

(In reply to AuRiMaS666 from comment #57)

Hello,

Upgraded Win 10 today from 1909 to 20H2 and started having this issue as well. Nothing similar ever happened before while using WebRender. Everything apart from the upgrade is exactly the same on this machine, so must be something to do with those new "multi monitor features".

FF 82.0
2560x1440@144Hz + 2560x1440@60Hz
1080 Ti on 456.98 drivers
HAGS on vs. off doesn't seem to make a difference.

Flickering seems to happen only on 144Hz screen while video is playing on 60Hz one, not the other way round.

Win v2004 was supposed to improve support for multi-monitor / multi-refresh setups but, as you can see, apparently not. Just seems to keep implying Microsoft did something wrong since v2004. 20H2 made no improvement either. Any chance you can test with NVidia 457.09 drivers? Seems to be a flicker fix but I can't imagine it's so monitor specific as is mentioned in comment 66.

(In reply to Arthur K. [He/Him] from comment #66)

Although I am not optimistic, I noticed this in the release notes of the newly minter 457.09 drivers:

"Random flicker may occur in multi-monitor configurations when G-SYNC is enabled. Flickering occurs on Dell S2417DG and Dell S2716DG monitors when playing YouTube or Twitch videos at 144 Hz. [3147515]"

Thanks Arthur! I was not aware of Nvidia bug 3147515.
I've asked the person who filed and reproduced Nvidia bug 3147515 to help us try to reproduce Nvidia bug 2993601, which I filed for this issue specifically.

(In reply to aleino from comment #68)

(In reply to Arthur K. [He/Him] from comment #66)

Although I am not optimistic, I noticed this in the release notes of the newly minter 457.09 drivers:

"Random flicker may occur in multi-monitor configurations when G-SYNC is enabled. Flickering occurs on Dell S2417DG and Dell S2716DG monitors when playing YouTube or Twitch videos at 144 Hz. [3147515]"

Thanks Arthur! I was not aware of Nvidia bug 3147515.
I've asked the person who filed and reproduced Nvidia bug 3147515 to help us try to reproduce Nvidia bug 2993601, which I filed for this issue specifically.

You're welcome. The thing that caught my eye was "...when G-SYNC is enabled." I don't have the setup to repro myself nor do I install the NVidia control panel when I update drivers. I'm also not a gamer. I'm curious about anyone who's got access to this setting to check with it on and off. Could it really be as simple as disabling this in NVidia Control Panel? I don't know what the pros and cons are of doing so though.

(In reply to Arthur K. [He/Him] from comment #69)

You're welcome. The thing that caught my eye was "...when G-SYNC is enabled." I don't have the setup to repro myself nor do I install the NVidia control panel when I update drivers. I'm also not a gamer. I'm curious about anyone who's got access to this setting to check with it on and off. Could it really be as simple as disabling this in NVidia Control Panel? I don't know what the pros and cons are of doing so though.

I tried disabling gsync entirely on the monitor entirely, can still repro immediately just by scrolling the imgur.com front page, unfortunately.

By default, gsync is only enabled for exclusive full screen applications, where it serves to provide adaptative vsync by actually changing the monitor's refresh rate dynamicaly to match the framerate, instead of the other way around. This prevents tearing when rendering occurs at a framerate below the refresh rate.

Toggling to setting to enable gsync for windowed fullscreen doesn't seem to have an effect on the bug either.

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Ok, thanks for testing.

Reddit thread that seems related - https://www.reddit.com/r/firefox/comments/jmigpd/flickering_on_pdfs_and_image_heavy_sites_when/

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

(In reply to Arthur K. [He/Him] from comment #74)

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

Issue still present after these updates.

(In reply to Arthur K. [He/Him] from comment #74)

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

I have updated to the latest cumulative for 20H2, Firefox 82.0.3 and nvidia drivers 457.30.
I will test for a while and report, as I don't want to speak too quickly once again.

(In reply to alex from comment #76)

(In reply to Arthur K. [He/Him] from comment #74)

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

I have updated to the latest cumulative for 20H2, Firefox 82.0.3 and nvidia drivers 457.30.
I will test for a while and report, as I don't want to speak too quickly once again.

Having tested it in this configuration for some time now, the artifacting still occurs but significantly less so.
I am not sure what exactly changed, but while they still show up, they don't persist for as long.
For instance, scrolling the imgur front page and moving your cursor across thumbnails and previews was previously a surefire way of triggering it, now it occurs on first pass and returns to normal afterwards.

So, while it is not entirely gone, it seems to be somewhat better once more? It is however hard to tell, as previously whenever this occured Something Unknown would happen and cause it to come back in force, and perhaps I just haven't triggered this yet.

(In reply to alex from comment #77)

(In reply to alex from comment #76)

(In reply to Arthur K. [He/Him] from comment #74)

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

I have updated to the latest cumulative for 20H2, Firefox 82.0.3 and nvidia drivers 457.30.
I will test for a while and report, as I don't want to speak too quickly once again.

Having tested it in this configuration for some time now, the artifacting still occurs but significantly less so.
I am not sure what exactly changed, but while they still show up, they don't persist for as long.
For instance, scrolling the imgur front page and moving your cursor across thumbnails and previews was previously a surefire way of triggering it, now it occurs on first pass and returns to normal afterwards.

So, while it is not entirely gone, it seems to be somewhat better once more? It is however hard to tell, as previously whenever this occured Something Unknown would happen and cause it to come back in force, and perhaps I just haven't triggered this yet.

Glad to hear it. Have you bumped to 83 yet? There seem to be perf improvements in other aspects of the browser but just checking in regarding the visual ones. =)

I can reproduce this locally after updating to Windows 10 20H2

But I then reverted the windows update and can still reproduce the problem...

Aleino, have you had any luck trying to reproduce this inside Nvidia? What configurations have you tried?

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

Aleino, have you had any luck trying to reproduce this inside Nvidia? What configurations have you tried?

No, not yet.

We have tried on
Displays: 2560x1440@144Hz Gsync PG279Q monitor on DP and a 1920x1080@60Hz LG 27gl850 on HDMI .
GPU: 2080Ti and GTX 1070, both with 456.71 driver
Firefox version: 81.0.2 (verified that gfx.webrender.compositor is enabled)
Windows 10 version: 2004

Can you try Nightly? Release Firefox has had WebRender disabled on high refresh rates for a while.

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

Can you try Nightly? Release Firefox has had WebRender disabled on high refresh rates for a while.

I've asked the person with the mentioned test setup to give nightly a shot.
Thanks!

I just saw that Geforce 457.51 were released today. Nothing in release notes jumped out at me as it relates to this bug but wanted to mention one thing I saw in them in case it might be related.

• When setting the refresh rate higher than 100Hz, the color format switches from RGB to ycbcr422. [3053990]

(In reply to alex from comment #76)

(In reply to Arthur K. [He/Him] from comment #74)

(In reply to alex from comment #71)

I have also tried to reproduce with nvidia drivers 457.09. It unfortunately had not effect either, and I can still reproduce immediately.

Today is patch Tuesday but yesterday NVidia released 457.30. Could you test with both installed and report back later on today or tomorrow?

I have updated to the latest cumulative for 20H2, Firefox 82.0.3 and nvidia drivers 457.30.
I will test for a while and report, as I don't want to speak too quickly once again.

Any change with December patch Tuesday update and Geforce 460.79?

I'd like to add some information to this in case it helps.

Currently on Firefox 85.0b4, enabled WebRender Manually as it was disabled by default.

I have an RTX 3080 GPU, the 460.79 drivers and 2 monitors, 1 connected via DisplayPort 1440p 144hz and 1 by HDMI 1080p 60hz.

If I have a video running on the 1080p 60hz monitor, the contents of that window will flicker on top of videos on the 1440p 144hz monitor or when I scroll down a page. I have had similar issues with other applications not liking the refresh rate difference between the 2 monitors.

Lowering the refresh rate seems to make the flashing less frequent but does not resolve it.

Here is a video showing the flickering https://streamable.com/xxw01a the text is blurry due to compression but that shouldn't matter.

Interestingly the video recording also shows flashing on the smaller 60hz monitor which wasn't actually there. Which makes me think it's not a bug with Firefox itself, more some sort of bug with Windows Desktop Window Manager.

If I turn off WebRender this issue stops entirely.

(In reply to Arron from comment #87)

I'd like to add some information to this in case it helps.

Currently on Firefox 85.0b4, enabled WebRender Manually as it was disabled by default.

I have an RTX 3080 GPU, the 460.79 drivers and 2 monitors, 1 connected via DisplayPort 1440p 144hz and 1 by HDMI 1080p 60hz.

If I have a video running on the 1080p 60hz monitor, the contents of that window will flicker on top of videos on the 1440p 144hz monitor or when I scroll down a page. I have had similar issues with other applications not liking the refresh rate difference between the 2 monitors.

Lowering the refresh rate seems to make the flashing less frequent but does not resolve it.

Here is a video showing the flickering https://streamable.com/xxw01a the text is blurry due to compression but that shouldn't matter.

Interestingly the video recording also shows flashing on the smaller 60hz monitor which wasn't actually there. Which makes me think it's not a bug with Firefox itself, more some sort of bug with Windows Desktop Window Manager.

If I turn off WebRender this issue stops entirely.

Can confirm. Same exact issue happens to me. 60hz monitor causes flickering on 144hz monitor when a video is playing on the 60hz monitor while WebRender is manually enabled.

Issue is resolved if either WebRender is turned off or gfx.webrender.software is set to true

Nvidia 460.89 Driver
RTX 3070 GPU
Ryzen 5800X

I am going to look into the bug, though I do now have an environment to reproduce the problem.

"gfx.webrender.compositor set to false" changes the rendering from "DirectComposition + VirtualSurface" to "DirectComposition + SwapChain" on Win10. Then VirtualSurface usage might trigger the problem.

I see same symptom when I play Blu-ray with PowerDVD on a sub-display. The refresh rate of my all displays are 60Hz, but when I play a Blu-ray disc on a sub-display, only the display's refresh rate is changed to 24Hz (probably the movie of the disc is so). This symptom is gone when:

• I change gfx.webrender.compositor to false.
• A Firefox window is moved into the 24Hz'd display.
• Move PowerDVD window to the display which has Firefox window.

Oh, I forgot my information:

Description NVIDIA GeForce GTX 1060 6GB
Driver Version 27.21.14.6109
Driver Date 12-31-2020
Display0 1920x1920@59Hz
Display1 5120x2880@60Hz
Display2 3840x2160@23Hz
DisplayCount 3

I put PowerDVD to Display2 and Firefox to the others. Only Display2 is connected with HDMI, and the others are connected with DisplayPort.

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

I can reproduce this locally after updating to Windows 10 20H2

:jrmuizel, can you check if your problem could be addressed with "fx.webrender.compositor to false"?

Reproduced the issue with the following environment:

• Windows 10 Pro 20H2 19042.746
• Nightly 2021-01-26, clean profile
• GeForce GTX 1080 Ti
  • Driver: 461.40
• Dell AW2518H 1920x1080 144Hz, DisplayPort
• IO-DATA LCD-GC251UXB 1920x1080 60Hz, DisplayPor

steps:

1. Play https://vimeo.com/246618509 on 60Hz monitor
2. Scroll https://www.mozilla.org/en-US/ on 144Hz monitor

some notes:

• Doesn't reproduce on Windows 10 Pro 1909
• Doesn't reproduce if I set gfx.webrender.compositor pref to false and restart
• Doesn't reproduce if:
  • Swap the windows (play https://vimeo.com/246618509 on 144Hz monitor, and scroll https://www.mozilla.org/en-US/ on 60Hz monitor)
  • Place both windows in 144Hz monitor
  • Place both windows in 60Hz monitor
• Doesn't reproduce with the following combination:
  • 144Hz + 120Hz
  • 240Hz + 120Hz
• Reproducible also with the following combination:
  • 144Hz + 24Hz
  • 60Hz + 24Hz
• Still reproduces if I disable G-SYNC
• Reproducible also with previous video driver: 431.60
• Still reproducible if I play https://vimeo.com/246618509 on 60Hz monitor with Chromium Edge, instead of Nightly. but happens less frequently

Also, reproduces with single window with the following steps:

• Place the window with https://www.mozilla.org/en-US/ span across both display
• Scroll the page

in this case, the artifact is shown only in 144Hz's side of the window,
and this doesn't require playing video in other window.

Anyone had a chance to test the above with any build of what will eventually become Win 10 21H1/2104? Is WDDM 2.8 going to change things yet again?

Hy guys. I can reproduce the same problem, identical to those reported above. My specs:

Nightly 87.0a1 / NVIDIA Driver v461.40 / Primary monitor: 1920x1080 240hz / Secondary Monitor: 2560x1080 60hz / NVIDIA RTX 2060 SUPER / Insider Beta Channel 20H2 (Build 19042.782).

I wonder if display adapter might affect to the problem. On my laptop, even when Firefox used NVIDIA GPU for WebRender, Intel's display adapter was used for display. And I could not reproduce the problem on the laptop.

It seems helpful if about:support have display adapter info. Bug 1638709 is created for it.

added my about:support to help us investigate.

I could reproduce the problem with one PC with the steps of Comment 94. I also reproduced it with Chromium Edge and chrome browser(on 60 Hz HDMI display with video playback).

Aleino, we've been able to reproduce this in a bunch of places. Is there anything we can do to help you reproduce it?

RTX 2060 Super (Galax edition).
NVIDIA Driver: 461.40
Display 1: 1920x1080 (DELL AW2720HF) 240hz G-sync compatible and activated. DP port.
Display 2: 2560x1080 (LG Ultrawide 29UM68-P) 60hz HDMI port
Firefox Nightly 87.0a1

artifacts in website like a youtube and facebook. I can only reproduce at nightly version. Stable and beta are ok. My about:support are in Comment 99.

I used the following PC to reproduce it at comment 100.

https://www.amazon.co.jp/%E3%82%B2%E3%83%BC%E3%83%9F%E3%83%B3%E3%82%B0%E3%83%87%E3%82%B9%E3%82%AF%E3%83%88%E3%83%83%E3%83%97%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3-RTX2060-16GB%E3%83%BBSSD-%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%96%E3%83%A9%E3%83%83%E3%82%AF-%E3%80%90%E6%97%A5%E6%9C%AC%E6%AD%A3%E8%A6%8F%E4%BB%A3%E7%90%86%E5%BA%97%E5%93%81%E3%80%91%E3%80%90%E3%81%82%E3%82%93%E3%81%97%E3%82%93%E4%BF%9D%E8%A8%BC%E3%80%91G15DH-R7R2060S512/dp/B08DXSQR82/ref=sr_1_3?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&dchild=1&keywords=rtx2060+super+%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3&qid=1612250691&sr=8-3

(In reply to Gabriel Zilio from comment #102)

artifacts in website like a youtube and facebook. I can only reproduce at nightly version. Stable and beta are ok. My about:support are in Comment 99.

I wonder if WebRender is blocked on beta by high display frequency.

• https://searchfox.org/mozilla-central/rev/f982032c7c7618c626165bb557968f478a1952dc/gfx/config/gfxConfigManager.cpp#205

(In reply to Sotaro Ikeda [:sotaro] from comment #100)

I could reproduce the problem with one PC with the steps of Comment 94. I also reproduced it with Chromium Edge and chrome browser(on 60 Hz HDMI display with video playback).

But I could not reproduce the problem only with legacy Edge, Chromium Edge and chrome browser.

Flickering looked like different tiles' contents were rendered at different tiles for a shot time.

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

Aleino, we've been able to reproduce this in a bunch of places. Is there anything we can do to help you reproduce it?

Hi Jeff,

One of our QA engineers reproduced a while back.
The internal Nvidia bug was just moved from the stage where a QA engineer reproduces it, to the investigation stage.

We saw all of the detailed repro cases that have appeared lately. Those really help a lot -- thanks!

I just checked-in fix of Bug 1690145. It makes example compositor app build/run again. It is an simple app to run WebRender compositor. With the app, we could check the flickering easily. I used the following command under gfx/wr/example-compositor/compositor.

cargo run native large none 1600 1600

When I run the app on both displays(144Hz and 60Hz), the flickering happened only on 144Hz display.

aleino, I put up a somewhat reduced test case of the flickering here: https://bugzilla.mozilla.org/attachment.cgi?id=9203745

I can reproduce the flickering by just running compositor.exe and moving the window so that it is on both the 144Hz and 60Hz displays.

Do you have an update on the investigation inside Nvidia?

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

aleino, I put up a somewhat reduced test case of the flickering here: https://bugzilla.mozilla.org/attachment.cgi?id=9203745

I can reproduce the flickering by just running compositor.exe and moving the window so that it is on both the 144Hz and 60Hz displays.

Do you have an update on the investigation inside Nvidia?

No updates, but thanks for the test case. I'll put a link to it on the internal Nvidia bug.

I have also the same issue, using a second window on the second monitor to watch Netflix.

Software:
Firefox 86.0.1 Release channel (enabled webrender manually since it was automatically disabled for high refresh rate monitors, because of freezing on intervals on a certain game site https://www.legendsofidleon.com/ with it disabled).
Windows 20H2 (19042.867)
Current Nvidia driver 461.92 (but all previous versions affected since I added the second monitor, unfortunately I didn't note down initial version)

Hardware:
Asus Geforce 1070
Samsung 2560x1440 240hz monitor connected via Displayport
Asus 1920x1080 120hz monitor connected via HDMI (locked to 60hz)

Issue does not happen if:
"gfx.webrender.compositor" or "gfx.webrender.dcomp-win.enabled" booleans are set to false.
But both of these cause the hiccups on the site which forced me to force-enable webrender in the first place and also cause jerky framerate on Netflix if I run something graphically heavier on the first monitor.

"gfx.webrender.dcomp-win.enabled false" seems to perform better than "gfx.webrender.compositor false" (but I have no real performance data so that could placebo or with margin of error) but after a random amount of time will cause Firefox main window, on the https://www.legendsofidleon.com/ tab, to go completely white and freeze. Shutting down firefox in that state causes a singular firefox.exe zombie process that Sysinternals Process Explorer reports access denied on when I try to kill it and the FOSS Process Hacker tool reports that it can't kill an exiting process. Process remains a zombie until reboot.

Aleino, do you have any idea on a time frame for a fix here? Should we just disable DirectComposition on Nvidia GPUs?

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

Aleino, do you have any idea on a time frame for a fix here? Should we just disable DirectComposition on Nvidia GPUs?

Sorry about the delay. I don't know any timeframe. I just bumped the internal Nvidia bug that I filed for this issue a while back, since it hasn't seen any activity in a while.
Probably this still takes at least a month, but it'll be longer if the issue doesn't get prioritized.

I can't work on it myself, since it seems to require a particular setup.

I have found a way to always replicate this bug with my current setup detailed below:

• Open one Firefox window on each monitor
• Open pages with constantly running animations on both windows (I used https://meshgradient.com/ for my tests)
• The window on the higher framerate monitor should present artifacts

Important note: I can't replicate this bug when running one monitor at 120 Hz and the other at 60 Hz, which might be an acceptable solution for some people while the bug is being worked on

Hardware:
Gigabyte GTX 1060 6GB
Asus ROG Strix XG279Q running at 144 Hz
Asus VN247H running at 60 Hz

Software:
Windows 20H2 19042.867
Nvidia driver 461.92
Firefox 86.0.1

There is a similar sounding bug affecting NVIDIA GPUs on the Chrome bug tracker - https://bugs.chromium.org/p/chromium/issues/detail?id=1185538.

Would you be able to temporarily apply the test workaround mentioned in that bug (https://bugs.chromium.org/p/chromium/issues/detail?id=1185538#c10) and let us know if that resolves the issue you're seeing?

That will allow us to know if we're looking at the same underlying bug or if this is something different.

Still able to reproduce the issue, even with the mentioned registry change and the required reboot afterwards.

Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 87
Nvidia driver 461.92
Windows 20HZ 19042.870

(In reply to lavalampe from comment #116)

Still able to reproduce the issue, even with the mentioned registry change and the required reboot afterwards.

Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 87
Nvidia driver 461.92
Windows 20HZ 19042.870

No change with 465.89 I assume?

artifacts still happens.. no new updates?

nightly v89
nvidia 465.89
monitor 1 240hz
monitor 2 60hz

Bug 1704954 turns off DirectComposition in beta/release, and gives those users WebRender. I left it on in nightly for now until we fix this (or give up and disable in nightly too).

I can't seem to reproduce the issue any more. Recently installed a optional Windows update (KB5001391), maybe that changed something. Can someone confirm?

Specs:
Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 88
Nvidia driver 466.27
Windows 20H2 19042.964

(In reply to lavalampe from comment #120)

I can't seem to reproduce the issue any more. Recently installed a optional Windows update (KB5001391), maybe that changed something. Can someone confirm?

Specs:
Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 88
Nvidia driver 466.27
Windows 20H2 19042.964

Positive news. Can anyone else who's installed the KB5001391 preview update test as well?

I've been reading that this preview update is supposed to have the final bits to what will eventually become 21H1 once the enablement pack turns it on with, likely, the May '21 Patch Tuesday update or just shortly after with a separate update. Not likely working better now due to 466.27 as I've read nothing but horror stories about the 465.xx/466.xx driver releases.

(In reply to Arthur K. [He/Him] from comment #121)

(In reply to lavalampe from comment #120)

I can't seem to reproduce the issue any more. Recently installed a optional Windows update (KB5001391), maybe that changed something. Can someone confirm?

Specs:
Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 88
Nvidia driver 466.27
Windows 20H2 19042.964

Positive news. Can anyone else who's installed the KB5001391 preview update test as well?

I've been reading that this preview update is supposed to have the final bits to what will eventually become 21H1 once the enablement pack turns it on with, likely, the May '21 Patch Tuesday update or just shortly after with a separate update. Not likely working better now due to 466.27 as I've read nothing but horror stories about the 465.xx/466.xx driver releases.

After running the mentioned setup above for a few hours, I have to admit I can still see artifacts but only very rarely. It's definitely way better than before though.

(In reply to lavalampe from comment #122)

(In reply to Arthur K. [He/Him] from comment #121)

(In reply to lavalampe from comment #120)

I can't seem to reproduce the issue any more. Recently installed a optional Windows update (KB5001391), maybe that changed something. Can someone confirm?

Specs:
Nvidia GTX 1060 6GB
One 144 Hz Monitor, One 60 Hz
Firefox 88
Nvidia driver 466.27
Windows 20H2 19042.964

Positive news. Can anyone else who's installed the KB5001391 preview update test as well?

I've been reading that this preview update is supposed to have the final bits to what will eventually become 21H1 once the enablement pack turns it on with, likely, the May '21 Patch Tuesday update or just shortly after with a separate update. Not likely working better now due to 466.27 as I've read nothing but horror stories about the 465.xx/466.xx driver releases.

After running the mentioned setup above for a few hours, I have to admit I can still see artifacts but only very rarely. It's definitely way better than before though.

This is on FF88?

Nevermind. I see you said FF88.

I have pretty much the same setup as lavalampe and see no improvement at all on FF88 and Nightly. On FF89 Beta 6 with DirectComposition off, haven't seen any glitches yet.

aleino, do you have an update on this from the Nvidia side?

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

aleino, do you have an update on this from the Nvidia side?

I speculated on the internal Nvidia bug 2993601 that the following might be related:
https://bugs.chromium.org/p/chromium/issues/detail?id=1185538#c21
As a result, the Nvidia bug was closed.

Someone should first check if update KB5000842 from Microsoft resolves the issue.
If not, I'll at least re-open the Nvidia bug.

(Thanks for reminding me to update here!)

Windows 21H1 19043.1023
Nvidia GTX 1080 Ti / 466.55
Primary 144 Hz / secondary 60 Hz

Gave a quick spin on the latest Nightly and haven't noticed any flicker when browsing and scrolling around on the main screen, even with the video playing inside another browser or dedicated video player on the secondary screen.

Flickering starts when hovering the mouse over / scrolling open window or just by dragging around any app window (browsers, Windows Explorer, PC Settings, Tidal, Steam... ) on the secondary screen. It even happens when hovering over Windows taskbar icons.

Aleino, the flickering still happens for me with the sample app with the 2021-05 Cumulative Update for Windows 10 Version 2004 for x64-based Systems (KB5003173). Please reopen the Nvidia bug.

Disabling MPO planes had already been tested with no effect and had also been reported here on comment 116

Seems also to occur with AMD:
https://www.reddit.com/r/firefox/comments/o7bp2b/weird_glitch_i_get_from_time_to_time/h5ir2e3/

• Not using nightly.
• I have a 1440p@144Hz monitor and two 1080p@60Hz. On a Ryzen 9 5950x & 3090 setup.

Not to muddy the waters here but has anyone tested for this issue with the Windows 11 preview yet? Based on what I saw here yesterday (https://downloadcenter.intel.com/download/30579/Intel-Graphics-Windows-DCH-Drivers), it appears to have an October 2021 RTM date.

(In reply to Darkspirit from comment #131)

Seems also to occur with AMD:
https://www.reddit.com/r/firefox/comments/o7bp2b/weird_glitch_i_get_from_time_to_time/h5ir2e3/

• Not using nightly.
• I have a 1440p@144Hz monitor and two 1080p@60Hz. On a Ryzen 9 5950x & 3090 setup.

Isn't that just an AMD CPU with a Nvidia GPU?

Aleino, any update from Nvidia on this bug?

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

(In reply to Darkspirit from comment #131)

Seems also to occur with AMD:
https://www.reddit.com/r/firefox/comments/o7bp2b/weird_glitch_i_get_from_time_to_time/h5ir2e3/

• Not using nightly.
• I have a 1440p@144Hz monitor and two 1080p@60Hz. On a Ryzen 9 5950x & 3090 setup.

Isn't that just an AMD CPU with a Nvidia GPU?

Sorry. I did not parse "Ryzen 9 5950x & 3090" as "Nvidia RTX 3090" because I expected Nvidia to be "unaffected" since DirectComposition should be force-disabled for non-Nightly on Nvidia.
The user confirmed that manually disabling gfx.webrender.compositor in Firefox Stable fixed the problem.
Does this blocklist rule still work after it has been changed and moved around multiple times?

The blocklist rule works for me locally, but perhaps there's something funny going on. We're obviously not doing a good enough job detecting situations when the problem will occur.

I can confirm I have the same issue as shown here: https://old.reddit.com/r/firefox/comments/glfgm1/weird_artifact_issue/fr6jnvg/

Even though I have the latest Windows Updates (winver: Version 20H2 (OS Build 19042.1165).
My GPU is a NVIDIA GeForce GTX 960 GPU (Gigabyte GV-N960WF2OC-4GD (rev. 1.0)) with the latest Geforce driver 471.68.

My setup is that I connect my screen (Iiyama GB2560HSU-B1, 1080p 144hz) with Displayport, and for audio I use the HDMI output to my Yamaha RX-V375. It's possible the HDMI to such an old AVR will not support 144hz. Perhaps the difference in Hz of the output is causing the artifacting?

Disabling gfx.webrender.compositor seems to help.

It was probably turned on either because I used to have an AMD GPU, or because I tried to see if it would resolve the performance issues with Outlook.com : https://bugzilla.mozilla.org/show_bug.cgi?id=1694126

I can confirm the issue...

I am using Firefox Nightly (v93)

Latest version of Windows 10 Pro (v21H1 19043.1165 120.2212.3530.0)

Latest version Nvidia drivers (v471.68)

Latest version Intel drivers (27.20.100.9749)

Primary screen is from very fresh laptop MSI Stealth 15M A11SDK (1920x1080x144Hz)
Secondy screen is Iiyama PLT2250MTS connected over VGA with UNITEK HDMI to VGA adapter (1920x1080x60Hz)

Interesting observation... in general it is better with "gfx.webrender.compositor" set to FALSE but... less artifacts/flickering but no 100% good
but
every time when on secondary screen twitch stream froze with a warning that "you are not watching this on twitch website directly" page my other stream on primary screen went really bad... like heavily interlaced with that image from secondary screen....

is there any combined set of settings to change to get rid of this artifact/flicker thing completely ?

(In reply to DagiLajki from comment #138)

is there any combined set of settings to change to get rid of this artifact/flicker thing completely ?

Set both monitor's refresh rate to 60Hz I think worked for some. Can you verify?

(In reply to Arthur K. [He/Him] from comment #139)

(In reply to DagiLajki from comment #138)

is there any combined set of settings to change to get rid of this artifact/flicker thing completely ?

Set both monitor's refresh rate to 60Hz I think worked for some. Can you verify?

Nope... Refresh rate for laptop builtin screen is fixed only to 144Hz

I'm having the same exact issue. I'm using a GeForce GTX 1060 6 GB graphics card with the latest NVIDIA drivers on Windows 10.

My main monitor is running 1080p@144hz and my second monitor is running 1080p@60hz.

My CPU is an Intel(R) Core(TM) i5-4690K with 8GB of RAM if that matters.

Has anyone tested with the 510.10 (Dev Channel) drivers with respect to this bug?

I reached out to Microsoft again and they said that this issue should be fixed in Win11 insider builds greater than 22000. If anyone can try that it out it would be good to confirm that it's fixed.

I could not reproduce the problem on Win11(22000.348) even without Win11 insider builds. With same PC, I was able to reproduce the problem with the STR of Comment 94 with Win10.

:arai, :masayuki, can you check if the problem still happen with nightly on Win11?

I don't have the environment to reproduce this on Win11, but I cannot reproduce this bug on Win10 21H2 after updating the graphic driver to 497.09 (I reproduced this bug with an older version of the graphic driver before updating it).

Ah, no, I reproduced this in treeherder.

I cannot even reproduce the issue while scrolling, with the same environment and same versions as comment #94 now.

• Windows 10 Pro 20H2 19042.746
• Nightly 2021-01-26, clean profile
• GeForce GTX 1080 Ti
  • Driver: 461.40
• Dell AW2518H 1920x1080 144Hz, DisplayPort
• IO-DATA LCD-GC251UXB 1920x1080 60Hz, DisplayPort

No artifact is displayed while scrolling.
there might be some other configuration I've missed (I've changed some peripherals since then)

what I observed is the following:

• the frame rate of the scroll on 144Hz screen is reduced, depending on 60Hz/24Hz screen frequency
• similar artifact is observed while resizing window on 144Hz screen. page content is shown on title bar

will check the frame rate and artifact while resizing on Windows 11 after upgrade

The situation is same as comment #148 on Windows 11, with latest nightly

• Windows 11 Pro 21H2 22000.318
• Nightly 2021-12-08, clean profile
• GeForce GTX 1080 Ti
  • Driver: 461.40 and 497.09
• Dell AW2518H 1920x1080 144Hz, DisplayPort
• IO-DATA LCD-GC251UXB 1920x1080 60Hz, DisplayPort

The result:

• No artifact is displayed while scrolling
• the frame rate of the scroll on 144Hz screen drops depending on 60Hz/24Hz screen frequency
• artifact is observed while resizing window on 144Hz screen. page content is shown on title bar, especially if other screen uses 24Hz
  • Doesn't reproduce if I set gfx.webrender.compositor pref to false and restart

(In reply to Sotaro Ikeda [:sotaro] from comment #144)

I could not reproduce the problem on Win11(22000.348) even without Win11 insider builds. With same PC, I was able to reproduce the problem with the STR of Comment 94 with Win10.

I feel like I read somewhere that some additional fixes around multi-monitor+multi-refresh went into 21H2. Was your Win 10 test done with 21H2?

(In reply to Arthur K. [He/Him] from comment #150)

I feel like I read somewhere that some additional fixes around multi-monitor+multi-refresh went into 21H2. Was your Win 10 test done with 21H2?

Sorry, I did not tested on 21H2 Win10. I already updated to Win11 when it was released.

(In reply to Tooru Fujisawa [:arai] from comment #149)

The situation is same as comment #148 on Windows 11, with latest nightly

The result:

• No artifact is displayed while scrolling
• the frame rate of the scroll on 144Hz screen drops depending on 60Hz/24Hz screen frequency
• artifact is observed while resizing window on 144Hz screen. page content is shown on title bar, especially if other screen uses 24Hz
  • Doesn't reproduce if I set gfx.webrender.compositor pref to false and restart

Thank you for the confirmation! Then the problem still exists on Windows 11 Pro 21H2 22000.318, though the symptom became less often.

Hmm i seem to reliably trigger the display compositor glitches by having a video playing on a secondary monitor, and a website like reddit on primary 144hz monitor and just scrolling down, it is fixed on insider builds but stable release for those are months away.

Has this improved any with FF97 and NVidia 511.65/511.72 series drivers?

Clear needinfos that are pending on inactive users.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Has this improved any with FF97 and NVidia 511.65/511.72 series drivers?

Still an issue on Nightly, even with new cards and drivers. Looking through the severities, and the amount of likely dupes/see-also's this has accumulated, I think we should reconsider making this an S2. There aren't going to be too many users affected (but multi-monitor isn't that uncommon), there's no really a satisfactory workaround until you find this bug and flip the hidden pref (couldn't we auto-disable webrender.compositor if we know this case is broken?), and the usage impact is major - the browser becomes nearly unusable on some sites.

Ah, this shouldn't affect non-Nightly users, so that's good: https://searchfox.org/mozilla-central/rev/2022d34edd5817948b27f093cd203ae6adb18a25/gfx/config/gfxConfigManager.cpp#366

Looking at the first video https://streamable.com/mjj7mu and the corresponding chromium bug https://streamable.com/fufgt0 and the scrolling video on the reddit thread https://www.reddit.com/r/firefox/comments/jmigpd/flickering_on_pdfs_and_image_heavy_sites_when/ I can say that this is DComp using the wrong textures for some of the tiles on certain frames, the tiles are never in the wrong positions but the binding to a texture is wrong some of the time, I understand the DCLayerTree code behind this so I have some ideas on how to investigate this in the code. But the fact it also occurs on chromium (which uses only SwapChains, whereas Firefox uses VirtualSurfaces, a completely different approach) makes me think this is a bug in interaction between nvidia drivers and DWM with internal race conditions that alter the interpretation or contents of the DWM command buffer being submitted, possibly depending on timing of processes updating the compositor state with separate commits.

For those who can repro this issue, does it help to toggle gfx.webrender.dcomp-use-virtual-surfaces to false? Normally Firefox uses an IDirectCompositionVirtualSurface to represent the web page content, which is a tile layout of textures that the DWM (Desktop Window Manager) will put on the screen, turning this pref to false makes it use some dozens of individual surfaces (IDirectCompositionVisual2 + IDirectCompositionSurface) instead, in theory this should not change how it looks but if it does it may be an interesting insight.

I will attempt to reproduce this problem once I get the hardware in hand to do so. Another theory is that it may involve vram clock stepup/stepdown on bursts of GPU activity interfering somehow with the CRTC or MPO (but MPO was already ruled out), I'm not entirely sure how that could cause the wrong texture to be shown on normally invisible tiles though (which seems like a distinctly DWM bug as empty tiles are likely not sent to the GPU).

:ahale is working for this bug.

I'm able to reproduce this bug on Windows 10 22H2 with RTX 3080 Ti, 360hz monitor and 60hz monitors, by opening the lofi girl hip hop stream ( https://www.youtube.com/watch?v=jfKfPfyJRdk ) and moving the window to split any part of the window across 360hz and 60hz monitors, this causes the compositor tiles to periodically glitch, often in accordance with the chat scrolling. I can reliably trigger the glitches by rapidly moving the mouse over the video area repeatedly.

Results of my testing:

• gfx.webrender.dcomp-use-virtual-surfaces - true/false does not affect the bug
• gfx.webrender.dcomp-video-overlay-win - true is default, false makes the glitch happen more often and the video tiles can appear in other parts of the window when it glitches, whereas normally the video swapchain never glitches
• gfx.webrender.dcomp-video-sw-overlay-win - true/false does not affect the bug
• gfx.webrender.dcomp-video-vp-scaling-win - true/false does not affect the bug
• gfx.webrender.dcomp-win.enabled - false makes the bug go away by disabling DirectComposition (so the window is just a single swapchain, and video is blitted using D3D11 into the swapchain as part of internal compositing) - we already knew this, but it's always worth confirming the workaround we use
• gfx.webrender.debug.dcomp-redraw-regions (a debugging aid) - true makes the problem slightly worse besides the expected flashing
• layers.offmainthreadcomposition.force-disabled - true makes the problem significantly worse
• gfx.webrender.multithreading - true/false has no effect
• layers.gpu-process.enabled - false stops the bug - unfortunately this seems to be due to WebRender failing to start properly with this setting, so it's punting to software rendering.

• Firefox profiler in Nightly mode prevents the issue by disabling dcomp
• Firefox profiler in Graphics mode significantly reduces the issue but it still occasionally glitches, which points toward this being a race condition

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

• Bug 1783707: S2

:ahale, could you consider increasing the severity of this bug to S2?

For more information, please visit auto_nag documentation.

I captured a video with OBS of the severe glitching on a couple websites with gfx.webrender.debug.force-picture-invalidation true.

With that pref set to false (default), it is difficult to get glitches to occur but they can stick around for indefinite periods of time until the mouse overs over the area.

This video as made with monitors that are 1920x1080@360hz (not in the video), 2560x1600@60hz (captured a 1920x1080 portion of this monitor for the video), and 2560x1600@60hz (not in the video).

If I make either 60hz monitor the primary desktop display it prevents the glitch, glitches only occur if the 360hz monitor is the primary display, but they can occur on any monitor - the same glitches occur almost constantly constantly on the 360hz monitor when moving the mouse, but video capture of a 360hz display at 60hz didn't seem entirely worthwhile to show it.

Same experiment as above but on the 360hz monitor, capturing at 60hz in this case to avoid a gigantic file, the glitching is much more constant than it looks in the video.

Question for anyone who can reproduce this issue on Firefox Nightly - does the issue occur on Windows 11 at all? I can reproduce this in Firefox Nightly on Windows 10 but no luck with Windows 11 22H2, I don't have a pre-22H2 Windows 11 install to test on at the moment.

Attached a video of the artifacting seen in compositor.exe for comparison to Firefox, these may be distinct issues.

Seeing identical glitching in old and new versions of the example compositor binary.