Terminal: GSync/Freesync refresh rate / FPS drops when using Terminal

I don't believe anyone on the dev team has a 144Hz monitor, so if someone in the community would be willing to help us debug this, the help would be greatly appreciated.

I've been dealing with this same problem the past few days. The only fix I've found so far is to disable G-Sync for Windows Terminal.

1. Open NVidia Control Panel.
2. On the left, select Manage 3D Settings.
3. Select the Program Settings tab.
4. You will have to add the Windows Terminal app to the list of programs in the drop down.
5. One of the options in the box should show G-Sync is enabled. Disable it.
6. Apply changes.

This only treats the issue though, not the source. I've never had any other UWP apps have this issue before, so this is likely a Windows Terminal issue.

I encountered the issue with a Nvidia GTX 1080 Ti and this 144hz Dell G-Sync monitor. I've made sure I have the latest Nvidia drivers installed, but I have not tried any pre-release drivers.

Can confirm, after explicitly disabling G-Sync for Terminal (and restarting
it) the issue is gone. Agreed that this treats the symptoms rather than the
issue. At least we now have a workaround :+1:

On Fri, May 10, 2019 at 4:27 PM mblowey notifications@github.com wrote:

I've been dealing with this same problem the past few days. The only fix
I've found so far is to disable G-Sync for Windows Terminal.

1. Open NVidia Control Panel.
2. On the left, select Manage 3D Settings.
3. Select the Program Settings tab.
4. You will have to add the Windows Terminal app to the list of
   programs in the drop down.
5. One of the options in the box should show G-Sync is enabled.
   Disable it.
6. Apply changes.

This only treats the issue though, not the source. I've never had any
other UWP apps have this issue before, so this is likely a Windows Terminal
issue.

I encountered the issue with a Nvidia GTX 1080 Ti and this 144hz Dell
G-Sync monitor
https://www.dell.com/en-us/shop/dell-24-gaming-monitor-s2417dg/apd/210-aizs/monitors-monitor-accessories.
I've made sure I have the latest Nvidia drivers installed, but I have not
tried any pre-release drivers.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Terminal/issues/649#issuecomment-491288003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ4X3HNJEYYNFGNVJEUF7LPUVZ2TANCNFSM4HL63MAQ
.

Same here. I have Gsync screen and card and the Terminal is lagging like crazy. My poor 165hz screen :(

Same here as well. 165hz G-Sync monitor, GTX 1070, low FPS in Terminal.

I have a 144Hz G-Sync compatible (FreeSync) display. A low FPS issue was also encountered when G-Sync was enabled for window (non-full screen) applications.

My monitor has an FPS indicator. I recorded a video to show the FPS changing when I ran the terminal. When the terminal does not have focus, the FPS is 144. When the terminal gets the focus, the FPS is usually 48 (the lower limit of the VRR refresh rate of my display. VRR: Variable Refresh Rate), and rises briefly when the content is updated, and then returns to the minimum refresh rate (48FPS) again.

My Video:
https://youtu.be/wokdiOQzwnU
Forgive my loss of focus (due to the curved screen) and background noise (You can mute it).

You can also download a video file with HEVC 240FPS (low bit rate) here:
http://qiniu.img.hu60.cn/file-hash-mp4-fb6775bfceeb0577b7244c58851f85a983686237.mp4

Note: This monitor has not passed the Nvidia compatibility test, so it has flicker and jitter when the VRR refresh rate fluctuates drastically. The certified G-Sync display may not have jitter, but the input delay (mouse movement speed) at low refresh rates is obvious.

From the FPS changes in the video, Windows Terminal is a typical VRR unfriendly GPU acceleration application. Such an application usually does not draw anything when the content is not updated (so FPS is 0, the Nvidia driver will trigger a timeout redraw mechanism to keep the display's minimum refresh rate), and draws only when the content is updated (the refresh rate rises briefly).

Such an application would cause a low-end VRR display (usually an early G-Sync / FreeSync display) to flicker and significantly increase the input delay when VRR is turned on.

From the current situation, disabling VRR (G-Sync) for Windows Terminal is the only correct choice.

Reference: Why VRR display flicker in some scene
https://pcper.com/2014/12/a-look-into-reported-g-sync-display-flickering/

So I have had this same issue on my G-Sync enabled monitor and after poking around the code I have been able to narrow down what the cause is. For those unfamiliar G-Sync is an NVIDIA technology that syncs the refresh rate of your monitor with the frame rate on the screen.

This particular issue occurs if you have G-Sync option set to Enabled for windowed and full screen mode in the NVIDIA Control Panel on G-Sync capable systems. Because Windows Terminal uses DirectX for drawing fonts the Nvidia drivers incorrectly think that you are playing a game in windowed mode with the option shown below enabled.

If you set the option to Enabled for full screen mode the terminal's low FPS will not drop the G-Sync monitors refresh rate and everything will work as expected.

It seems that the low FPS (and low refresh) is due to the fact that the screen is only re rendered for changes for performance reasons. In an idle state the screen is only refreshed by the blinking cursor causing the FPS to drop around 42. If you start typing the frame rate will go up higher and you can visibly see the refresh rate change.

This is a somewhat unusual situation with a few options to solve it.

• Disable the windowed mode option when you want to use the Windows Terminal with G-Sync enabled (not ideal)
• Re draw the screen every cycle boosting the FPS of the window to the max refresh rate of the monitor (also not ideal as this will tank performance)
• Ask Nvidia to add an exception to their drivers for Windows Terminal (not sure if possible).

I do not have the hardware to test but this may also be an issue with FreeSync monitors as well. For now the simple fix is to set the G-Sync option to Enabled for full screen mode in the NVIDIA Control Panel.

As others have stated the best solution is to create an application profile for the terminal that disables GSync just for this app. NVIDIA can release profiles for games/programs with driver updates and they often do exactly this every time you update your drivers so I think best course of action is to report to NVIDIA so they can create a workaround for the unexpected behavior with the new terminal.

It seems that the low FPS (and low refresh) is due to the fact that the screen is only re rendered for changes for performance reasons

Oh well that makes sense. When all we had was a GDI (CPU) renderer, we'd obviously want to only repaint on changes. However, with the DX renderer, maybe that's not so much of a problem.

@miniksa is there any way we could trigger a fake frame at the GPU's framerate? So that even if there was nothing new, we wouldn't drop the FPS?

Confirmed this happens on build 18990, perfect work around is to disable G-Sync when not full screen.

I experienced the same issue and can confirm that disabling G-Sync for windowed mode helped.

@zadjii-msft, I did fake it out for the previous attempt at fixing this without having one of these monitors. It didn't work once I gave the branch to people with the monitor to try.

We need this hardware or we need one of the folks complaining about this to also have the skills to build from source and debug this.

I was going to volunteer to help debug, but it seems I can no longer reproduce the issue. I have confirmed that Windows Terminal is set to use G-Sync, but I am no longer seeing any frame rate drops when interacting with the app.
I haven't changed any hardware since my first response, but I did fully re-install Windows a few weeks ago.

I was going to volunteer to help debug, but it seems I can no longer reproduce the issue. I have confirmed that Windows Terminal is set to use G-Sync, but I am no longer seeing any frame rate drops when interacting with the app.
I haven't changed any hardware since my first response, but I did fully re-install Windows a few weeks ago.

Interesting. Could be a driver thing then maybe? Thanks for the data point, @mblowey.

@miniksa Interesting issue, I just open my computer, and I enable G-SYNC for all windowed applications, and even after rebooting, I cannot reproduce this issue.

I also did not changed any hardware AND SOFTWARE (did not re-install or update Windows, did not re-install or update my graphic card driver, did not re-install or update my Windows Terminal) since my first response here https://github.com/microsoft/terminal/issues/649#issuecomment-544209435

I used to follow this comment https://github.com/microsoft/terminal/issues/649#issuecomment-491288003 to solve this issue

Also, I install lots of games from Steam after my first comment, maybe they install some important graphic dependencies then solve this issue.

If somebody experiencing this issue, try to do this

1. follow this comment https://github.com/microsoft/terminal/issues/649#issuecomment-491288003
2. reboot
3. REVERT STEP 1

might be able to tell if this is caused by NVIDIA driver

Can confirm on Windows 10 Build 10.0.19033.1, using latest Nvidia driver 441.20 with an ASUS GTX 2080, this problem still exists. If I turn off G-SYNC for Windowed and Full Screen Mode and switch back to "Enable for full screen mode" only, it behaves as it should with normal performance. I'm using the latest Terminal version (as of 11/26/2019, sorry not sure how to get the version directly.) Not sure what else I can do to help, but I thought I'd at least report that the issue is still there.

Edit: Also confirmed that the method of adding an application exclusion to the Nvidia Control Panel tool does still work. Didn't know you could do that, so thank you for sharing! Might fix a similar problem I've seen with Quicken. :)

As @jefmes noted above, I've reproduced this issue, with the same win 10, Terminal, driver and graphics card.

I had the same issue with the current Version 0.7.3451.0 on a 144hz G-Sync display. After I set the Monitor Technology to "Fixed Refresh" and the Vertical Sync setting to "Fast" in the Nvidia Control Panel the problem went away.

I'm running a GTX 1070, Driver Version 441.66 on Windows 10 Insider Build 19041.1.

I understand how the confusion between the terminal and the graphics driver arises, what I don't understand is how a small time developer like microsoft can't afford/justify a $200-300 monitor to investigate a bug. Maybe working together with nvidia to let windows flag an idle or desktop mode where even through directx is used, application refreshes are slow but the cursor still shows so you want max fps. Basically an automatic version of the workaround that MS can control.

FYI Cmder and Hyper terminal windows do not have an issue with redraw rates. Cursor movement when in focus and when dragging the windows of both these terminals works fine with whatever refresh rate I have set and are buttery smooth.

Why should the Windows Terminal window be any less capable of working with the current desktop refresh rate?

Why should the Windows Terminal window be any less capable of working with the current desktop refresh rate?

Because of a bug that we're still trying to pin down.

I don't know if it helps but I see the same behaviour not only in the new Windows Terminal but also in XAML Applications. The same workaround works in those cases as well.

Feels like the Nvidia driver needs better detection of what is a game and what is an application. Is anyone seeing this behaviour on AMD with FreeSync?

I've noticed that if you have enough text history to allow you to use the scrollbar to make the current line with the blinking cursor go 'offscreen', the refresh rate when dragging the window returns to normal.

OK, yeah, so I'm looking into getting hardware in my office so I might actually be able to do something about this.

I went and read about how this stuff works and it turns out the two technologies are more different than I realized.

Does this only happen with the NVIDIA pipeline of GSYNC monitor + NVIDIA graphics card? Or is it also possible with FreeSync monitor + AMD (or NVIDIA) graphics card?

I'm basically looking to find two parts that I can put on the acquisition list that are hopefully not as expensive as a GTX 1080Ti and an Asus PG279Q.

If anyone on this thread can chime in with recommendations or their report of if it happens in the FreeSync/AMD world, I'd really appreciate it.

I have Nvidia RTX 2060 and Acer XF270HU (which is FreeSync monitor) running in GSync Compatible mode. I also am experiencing this issue, but the method described in the comment https://github.com/microsoft/terminal/issues/649#issuecomment-568196580 does fix that.
Removing that fix makes the issue come back but not always. When I first removed those changes it didn't immediately drop down to ~60-40fps, but only after bit of time/couple of restarts.
Then I wanted to try and record that using Nvidia's GeForce experience recording feature. Once I started recording it jumped back to 144 and it stayed at that even while using terminal (this could be due to recording somehow forcing fixed refresh rate overall). Once stopped it stayed at 144 (even without that fix mentioned earlier). I tried the Ctrl+Shift+Win+B combination which had no impact and it still remained at 144.
So while the issue seems to still exist it's also quite hard to reproduce consistently and overall is pretty finicky, but it is not exclusive to pure GSYNC monitors.

I think I know how reproduce this problem consistently. I found this after reinstalling Windows and wondering why I never had terminal lag once :smile:

Switching it back to "Enable for full screen mode" or disabling it completely and the problem is gone.

I think you can even reproduce this behavior on a non G-Sync 60hz display connected via DP. The only difference is such a configuration doesn't make sense and the notice from the driver that Nvidia didn't this display yet.

But I think there is still more to it. What I show on the screenshot is kinda "misconfiguration" and not the default setting. And what if I set it up like that because I want to play games in windowed mode and still use G-Sync?

What I don't understand is how it even slows down the system cursor. Shouldn't the cursor, the window drawing loop and the update loop be independent?

I think I know how reproduce this problem consistently. I found this after reinstalling Windows and wondering why I never had terminal lag once 😄

Switching it back to "Enable for full screen mode" or disabling it completely and the problem is gone.

I think you can even reproduce this behavior on a non G-Sync 60hz display connected via DP. The only difference is such a configuration doesn't make sense and the notice from the driver that Nvidia didn't this display yet.

But I think there is still more to it. What I show on the screenshot is kinda "misconfiguration" and not the default setting. And what if I set it up like that because I want to play games in windowed mode and still use G-Sync?

What I don't understand is how it even slows down the system cursor. Shouldn't the cursor, the window drawing loop and the update loop be independent?

I was experiencing this issue as well on a 3440x1440 144hz FreeSync2 monitor, and setting my GSync mode to Enable for full screen mode in the NVIDIA control panel fixed the issue for me. Agreed with above sentiment - application window lag was immediately noticeable.

Running Version: 0.11.1121.0

I think I know how reproduce this problem consistently. I found this after reinstalling Windows and wondering why I never had terminal lag once 😄

Switching it back to "Enable for full screen mode" or disabling it completely and the problem is gone.
I think you can even reproduce this behavior on a non G-Sync 60hz display connected via DP. The only difference is such a configuration doesn't make sense and the notice from the driver that Nvidia didn't this display yet.
But I think there is still more to it. What I show on the screenshot is kinda "misconfiguration" and not the default setting. And what if I set it up like that because I want to play games in windowed mode and still use G-Sync?
What I don't understand is how it even slows down the system cursor. Shouldn't the cursor, the window drawing loop and the update loop be independent?

I was experiencing this issue as well on a 3440x1440 144hz FreeSync2 monitor, and setting my GSync mode to Enable for full screen mode in the NVIDIA control panel fixed the issue for me. Agreed with above sentiment - application window lag was immediately noticeable.

Running Version: 0.11.1121.0

What specific monitor and graphics card models, @zackhorvath?

I am still interested in solving this at some point even if the pandemic has hardware procurement a bit.... delayed.

Thanks for the response @miniksa

I'm currently running a LG 34GK950F-B monitor with a NVIDIA GeForce GTX 1080ti (EVGA Model# 11G-P4-6393-RX). My specific NVIDIA driver is 26.21.14.4587.

I can provide additional information if requested!

No, that's fine, thanks @zackhorvath. I was hoping your repro setup wasn't a $900 monitor and $1100 graphics card and more like a $300 monitor with a $200 graphics card...

As I said it is reproducible with my cheap and old Samsung 60hz Full HD Display. All that is needed is a Nvidia GPU that can do some form of G-Sync or FreeSync and a DP Cable.

This issue is not isolated to Terminal when G-SYNC is set to "enable for windowed and full screen mode". I see the same behavior in some other apps as well, e.g.:

• Malwarebytes Anti Malware
• Git Fork
• WhatsApp Desktop

As I said it is reproducible with my cheap and old Samsung 60hz Full HD Display. All that is needed is a Nvidia GPU that can do some form of G-Sync or FreeSync and a DP Cable.

Sorry, my reading comprehension hasn't been great while quarantined. I missed that.

This issue is not isolated to Terminal when G-SYNC is set to "enable for windowed and full screen mode". I see the same behavior in some other apps as well, e.g.:

• Malwarebytes Anti Malware
• Git Fork
• WhatsApp Desktop

This is sounding more and more like an NVIDIA driver bug that I can't do anything about then...

I discussed this with @miniksa and I'm looking into a possible mitigation, fyi. I have the required hardware and can easily reproduce the problem.

For what it's worth, I've observed this in several other apps as well and some unexpected ones. For example, the Visual Studio Installer also exhibits the same issue. Every one of them appears to be UWP and/or XAML-based.

To be honest I also think it's an driver bug, but since this is happening all over the place in Windows and Nvidia GPUs aren't that uncommon I thought someone at Microsoft could forward this issue. It might be a stretch but those Nvidia driver are WHQL certified right? They should not break Windows.

Just mentioning that I also still had this issue with current versions of software (Windows Terminal Version: 0.11.1251.0), Nvidia GPU, and a Freesync monitor. The workaround in the 3rd comment still helped. I would say the other workaround of disabling G-sync for windowed applications is not so good, because at least I play some games in borderless windowed mode.

It seems that the best solution would be for Nvidia drivers to better detect applications that benefit from G-sync, be it games or other programs. But a built-in Nvidia profile for Windows Terminal specifically would be a low-effort fix.

But a built-in Nvidia profile for Windows Terminal specifically would be a low-effort fix.

I don't know what this means. What is this profile you speak of? Can I include a manifest next to our application to tell NVIDIA's drivers to back off on G-syncing it? Or is this something that NVIDIA have to include in their driver packages?

But a built-in Nvidia profile for Windows Terminal specifically would be a low-effort fix.

I don't know what this means. What is this profile you speak of? Can I include a manifest next to our application to tell NVIDIA's drivers to back off on G-syncing it? Or is this something that NVIDIA have to include in their driver packages?

They're referring to the nvidia application profiles you can setup in the nVidia control panel, but as far as I can tell, that's not a viable solution. No matter what settings I've selected for the application-specific profile for Windows Terminal, the behavior remains the same. If someone has a working combination they've found, it would be nice to share as that might give me some ideas on how to fix this in Terminal itself.

Also, as far as I'm aware, even if the profiles did work, nVidia has to be the one to include them in their driver package.

So far I've tried a variety of modifications to Terminal without success, including disabling vsync, application of DXGI_PRESENT_ALLOW_TEARING, DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING, etc. to no avail. I've made an inquiry to a few other experts in hopes that someone is aware of an application-specific workaround that can be applied, but there's no ETA for now.

This issue isn't specific to Windows Terminal.

So far I've tried a variety of modifications to Terminal without success, including disabling vsync, application of DXGI_PRESENT_ALLOW_TEARING, DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING, etc. to no avail. I've made an inquiry to a few other experts in hopes that someone is aware of an application-specific workaround that can be applied, but there's no ETA for now.

This issue isn't specific to Windows Terminal.

Thanks, @binarycrusader. Those were all the flags and things I was going to try if I could gain access to the hardware.

This seems to happen with Deezer Music (UWP), WhatsApp Desktop and a majority of Electron based applications, too. Somewhat unrelated, but NVIDIA "Web" drivers show this behavior with almost every macOS application.

Ooof, well it looks like the electron answer to this problem was ¯\_(ツ)_/¯

https://github.com/electron/electron/issues/3026

I'm also not sure that it's even fixed in chromium - this issue on their tracker is still open, though a few years stale at this point 😕

I wonder if changing https://github.com/microsoft/terminal/blob/e61968ca87de7fd9c08b50f63e8cccb01f240596/src/renderer/base/thread.cpp#L208-L212 to use IDXGIOutput::WaitForVBlank (https://docs.microsoft.com/en-us/windows/win32/api/dxgi/nf-dxgi-idxgioutput-waitforvblank) would help this issue...

See also: https://bugs.chromium.org/p/chromium/issues/detail?id=467617 and https://www.vsynctester.com/firefoxisbroken.html and https://bugzilla.mozilla.org/show_bug.cgi?id=1628137 and https://bugs.chromium.org/p/chromium/issues/detail?id=953970

@miniksa

What is this profile you speak of? Can I include a manifest next to our application to tell NVIDIA's drivers to back off on G-syncing it? Or is this something that NVIDIA have to include in their driver packages?

To clarify, I meant settings that Nvidia would have to include in their drivers. It already lists about 1000 programs in its built-in "Program Settings" list (games and applications that I don't have), and I thought they have some custom settings for all of those programs, but I'm not sure now.

@binarycrusader

No matter what settings I've selected for the application-specific profile for Windows Terminal, the behavior remains the same. If someone has a working combination they've found, it would be nice to share as that might give me some ideas on how to fix this in Terminal itself.

These settings fixed it for me:

I think I only set it to "Fixed refresh", I'm not sure why the other two settings appear bold. But all other settings are defaults.

User-defined profiles created via Nvidia's own current control panel appear to always reference apps by absolute path to the executable. This worked fine for other apps I used previously but since the Windows Store installs every single Windows Terminal update to a different directory the associated profiles were annoyingly short-lived.

I was already using Nvidia Profile Inspector in a few cases for more fine grained control and discovered that user-defined profiles created with that tool:

1. Match on executable name only without path
2. Allow adding multiple executables to a single profile
3. Allow custom names for clarity

It also gives a much better view into the hundreds of profiles Nvidia is already shipping with current driver bundles but which are hidden from their control panel. There are dozens of Microsoft apps already in there including Microsoft Win10 Store, Microsoft Visual Studio, etc. which tend to match a few different executables (without paths) and, in their Sync and Refresh section, override GSYNC - Application State to Force Off.

I now have a single __No_GSync profile (named to conveniently sort to the top of the list) for WindowsTerminal.exe (in any path) along with a handful of other apps that also use lazy redraws. Again the only setting I've overridden via the inspector in this __No_GSync profile is GSYNC - Application State to Force Off. When viewed back in Nvidia's own control panel the only displayed override for this profile is Monitor Technology which appears set to Not supported for this application and doesn't even allow changing this value in that view.

I'm hoping this is a more reliable set-it-and-forget-it solution for myself, and also that the Windows Terminal team can communicate with Nvidia to get a similar profile bundled into future driver releases.

Adding "experimental.rendering.software": true in settings.json on Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) resolves this issue for me.

I assume I incur some level performance loss but I don't feel it on my machine.

On my system, no such luck using the profiles to manage this. Using an nVidia profile to force GSYNC off seems to have no effect. I've tried every variation of executable and setting. I tried using both the nVidia Control Panel and the profile inspector tool.

I've also been unable to get the profile based solution to work. I noticed that in the NVIDIA control panel Windows Terminal never appears in the recently used program list when adding a custom profile. I suspect the NVIDIA drivers are somehow unable to recognize that Windows Terminal is running.

In case this might help someone else, these are my settings in the Nvidia Control Panel

Adding "experimental.rendering.software": true in settings.json on Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) resolves this issue for me.

I assume I incur some level performance loss but I don't feel it on my machine.

I'm experiencing this issue as well and the G-Sync profile changes didn't fix it, but this did. Thanks.

After working with it for a few more days the profile solution was mostly effective for me but I've had occasional periods where it doesn't apply to Windows Terminal specifically. I haven't seen this problem for any other app that's also in the same no-gsync profile.

In a period where my Windows Store-installed copy of Terminal was currently being ignored by the Nvidia profile I, on a hunch, downloaded the matching msix (1.0.1401.0) from the releases page and extracted the folder for the x64 version directly to my desktop. Launching that copy's WindowsTerminal.exe has gsync correctly disabled for its window while the Windows Store-installed copy that's still running simultaneously has its gsync enabled. Several consecutive restarts of each produce the same results.

No changes were made to profiles between those launches. In theory I'd expect the same profile to affect both of them equally such that neither uses gsync. I'm wondering if this might be a complication of the permissions and linking through wt.exe involved in launching the Store-distributed version that causes it to slip by Nvidia's current detection mechanism. I have no idea how to explain my existing profile also seemingly applying correctly to the Store copy most of the time... I purged all other user-defined profiles and tried to correlate other windows in use but haven't spotted any pattern.

I'll probably continue using the extracted version instead of the store version for a while to see if that's reliable. It has the added bonuses of being easy to set the working directory on its shortcut when pinned to the taskbar, and also presumably never being quietly killed while hosting a long-running terminal process when the store forces an update. Only thing apparently missing so far are the profile icons referenced by ms-appx paths.

As an aside I've also been testing with neovide (a gpu-based GUI front-end for neovim) that acts similarly in terms of lazy screen redraws and thus exhibits the same gsync refresh rate drop by default when it has nothing it needs to redraw. The nvidia profile solution applies to neovide with 100% reliability as far as I can tell. From experimenting there it also appears that nvidia profiles are only evaluated at initial app launch so adding/removing neovide.exe to/from my no-gsync profile while neovide is already running does not change its already-running gsync state but will on next launch. Might be useful to know for anyone else troubleshooting.

So that rules out a problem in DirectX because neovide uses Vulkan.. With more modern games, especially UWP-based games, only offering "Fullscreen Window Mode" instead of "Exclusive Fullscreen Mode" I wonder if G-Sync is even doing anything if we don't enable G-Sync for windowed mode.

This bug seems to grow out of scope of this repository though (and every other project where this happens too) so if no one is noticing this and nobody has any kind of contact to someone at Nvidia will this ever get fixed? It would be cool to use Windows and being able to play games with the hardware and features I bought instead of piling a bunch of workounds on my system.

For those using the Nvidia Control Panel / Manage 3D Settings workaround, could you clarify how you added Windows Terminal to the Program Settings dropdown? It's not appearing in the dropdown for me, and I'm not sure how to browse for the executable given it's installed from the Windows Store.

For those using the Nvidia Control Panel / Manage 3D Settings workaround, could you clarify how you added Windows Terminal to the Program Settings dropdown? It's not appearing in the dropdown for me, and I'm not sure how to browse for the executable given it's installed from the Windows Store.

It's been a while since I set mine up, but I believe I just made sure to have the program running when opening the panel, and it either showed up immediately, or I was able to hit "Add" in that screenshot I posted above and choose "Currently running programs" or something to that effect.

Not sure why the MSBOT closed this and all duplicate issues, because adding the setting "experimental.rendering.software": true in settings.json was the only way I could "fix" this issue on my machine

Meaning there is something going on with the rendering?

Not sure why the MSBOT closed this

This issue has not been closed, and it will remain not-closed until we can figure out a solution for people with dysfunctional graphics drivers. For now, software rendering _or_ telling the graphics stack to not treat Terminal like a game _is_ that workaround.

Not sure why the MSBOT closed this

This issue has not been closed, and it will remain not-closed until we can figure out a solution for people with dysfunctional graphics drivers. For now, software rendering _or_ telling the graphics stack to not treat Terminal like a game _is_ that workaround.

Unfortunately I also wasn't able to fix this through my dysfunctional graphics driver settings. It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.

The setting "experimental.rendering.software": true in settings.json fixed it for me as well on Nvidia RTX 2080. I feel this is the preferred solution over changing global settings in Nvidia's Control Panel.

UPDATE:

I'll take that back as. If you have two monitors: one with G-Sync high refresh rate and one with basic 60hz, putting the terminal on the 60hz screen will still cause all apps on the high refresh rate screen to run sluggishly.

ANOTHER UPDATE:

Using the setting "experimental.rendering.software": true, and updating Windows 10 to v 2004 fixed it for me.

It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.

It does not automatically appear in the dropdown, but it should appear in the detected applications list after pressing "Add" next to it.

It's not appearing in the Nvidia Control Panel/Manage 3D Settings/Program Settings dropdown for me either.

It does not automatically appear in the dropdown, but it should appear in the detected applications list after pressing "Add" next to it.

Unfortunately, it does not appear there either.. :/

Having the same issue with version 1.0 and gsync - framerate drops to about 40 fps, and monitor is flickering. makes windows terminal almost unusable

update: "experimental.rendering.software": true seems to work fine with Windows 2004

@robert-sandor As mentioned above in this thread, some users have had success with the setting "experimental.rendering.software": true.

@robert-sandor As mentioned above in this thread, some users have had success with the setting "experimental.rendering.software": true.

I have two 1070ti's in SLI, driver v446.14, and an Alienware AW3420DW at 120hz on the desktop. I was also experiencing the reduced frame rate issue. Adding this setting to the config resolved it.

Adding "experimental.rendering.software": true in settings.json on Windows Terminal Release Candidate v0.11.1333.0 (1.0rc2) resolves this issue for me.

I assume I incur some level performance loss but I don't feel it on my machine.

This fixed it for me. When can we expect this to be outside of experimental @zadjii-msft?
FYI: 2 monitors, 1 144hz Gsync the other 60hz

My workaround of bypassing the store by extracting the package to my own folder and running WindowsTerminal.exe directly has been 100% reliable for the past two weeks in terms of allowing an Nvidia profile to force-disable Gsync there. Leaving Gsync globally enabled and force-disabling it in specific apps like this is still my preferred solution. Degrading to software rendering seems undesirable.

I've tried a broad variety of other apps and scenarios on the current Nvidia driver version 446.14. Windows Terminal specifically installed via Windows Store is the only one I've encountered with this combo of 1) Gsync kicks in, 2) is undesirable, and 3) an app-specific Nvidia driver profile fails to disable it. This is including UWP games (eg. Astroneer - Astro-UWP64-Shipping.exe) installed via the Windows Store. That seemed a useful point of comparison for the packaging/permissions/delivery situation but Gsync kicks in there, works as I'd expect, and can still be disabled via an app-specific profile.

"experimental.rendering.software": true fixed it for me.

1080Ti with latest nVidia drivers as of this date, and Windows 10 2004.

What is the latest official word on this issue?
I would prefer to use my CPU cycles elsewhere.

Thanks for the solution guys.

Software rendering is still fairly performant: we are standing on the shoulders of giants, and we still only render regions of the screen that have changed. While it’s not accelerated, it’s the next best thing.

"experimental.rendering.software": true also fixed it for me.

1080 with the latest NVidia driver on Windows 10 Pro Build 2004.

Does this method have any performance issues? Because as far as i can see i had no issues so far.

"experimental.rendering.software": true also fixed it for me.

1080 with the latest NVidia driver on Windows 10 Pro Build 2004.

Does this method have any performance issues? Because as far as i can see i had no issues so far.

So far so good.

I had turned off gsync windows terminal preview well in before but I can't find windows terminal after driver clean update. And software rendering is not good way to fix because I want GPU accelerated term :(

Is there a way to manually add windows terminal to not use gsync? putting exe doesn't work for uwp I think.

Adding "experimental.rendering.software": true also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).

This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.

I can confirm what @krage is saying about the profile override not working in the case of Windows Terminal installed via the windows store. Something with UWP apps in general doesn't seem to play well with Nvidia profiles. I switched from using the windows store install of terminal to one managed by scoop (essentially mimicking the method @krage is using) and my Nvidia profile is correctly applied.

My Nvidia profile for Windows Terminal uses the following settings:

• Preferred Refresh rate (Acer X34): Highest Available
• Monitor Technology: Use Global Setting (G-Sync)
• Vertical Sync: Use Global Setting (Fast)

These settings resolve the issue for me.

I can also confirm that enabling "experimental.rendering.software": true fixes the issue. But I'd rather use hardware based rendering.

Hardware:

• Nvidia GeForce 1080 (pushes x34)
• Nvidia GeForce 1060 (6GB) (pushes other panels)
• Acer X34 (G-Sync Display)
• GS35UCR DP (Non G-Sync, 100hz Display)
• 2x HP N270h (60hz non G-Sync Display)

Versions

• Nvidia 446.14
• Windows Terminal (Unpackaged) 1.1.200615001
• Windows 10 2004 (Build 20150.rs_prerelease.200612-1734) (insider fast ring)

By the way, I've recently investigated whether this issue can be solved and the short answer is: Yes, but primarily no.
Yes, the issue can be alleviated, by doing the following:

• Remove this and...
• that line
• add DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING and DXGI_PRESENT_ALLOW_TEARING flags as explained here

_BUT_ I'd argue that this would be a bad idea to do, which is why I didn't submit a PR in the end. Because if you do all that, every non-Nvidia user will now also draw at the full frame rate of their display, which is simply unnecessary.
In my humble opinion Nvidia must fix this particular issue on their side, because it isn't just present in Windows Terminal, but rather _all_ UWP apps which use DirectX.

And on top of that the "Enable for Windowed and Fullscreen Mode" setting in the Nvidia Control Panel isn't the default setting either and has been known to break a lot of stuff in the past (which - I'm sure of - is why it isn't enabled by default in the first place). 🙈

Basically this all comes down to an nVidia issue/bug regarding DX11?

I recently got a new monitor (LG27850) and there is no more flickering, but I can feel the 60hz vs 144Hz difference when I Alt-tab from the terminal to another program and it feels funny.

@KrunoSaho I can't proof it and I could be wrong, but I'm fairly certain...
You can try all the "D2D" (Direct2D), "DWrite" (DirectWrite) and "DX" (DirectX) samples here and you'll notice that _all_ of them show the same issue as Windows Terminal does.
The _only_ UWP+DirectX app I ever found that doesn't have the same issue is the App Store version of Minecraft.
As such I believe that the underlying issue is Nvidia's heuristic, which decides whether a process should use GSYNC.

Everyone who doesn't strictly need it should disable "Enable for Windowed and Fullscreen Mode":

In my humble opinion this issue can be closed, as this behavior isn't present when using AMD GPUs, sort of ruling out the possibility of a bug in Windows Terminal or Windows in general.

Unfortunately we enabled the "Enable for windowed and full screen mode" setting because we strictly need it. If I don't do that, the windowed mode games won't be using G-SYNC at all. So that option is a must.
I also had this issue with Photoshop, but at least my disfunctional nvidia driver let me choose a fixed refresh rate for that app simply by appearing in the list of apps to choose from.

So if nothing else, if you could just make the terminal app appear somehow/magically in the list of apps of nvidia control panel 3d settings I would be more than happy.

I have submitted a bug report to nVidia about this. We will see what happens, if anything.

@electrofloat I haven't been successful yet at reproducing that bug yet... For me it shows up:

...and it properly allows me to change the "Monitor Technology", which fixes the issue. If it doesn't show up for you try to create a shortcut to the Terminal app on your Desktop, by dragging & dropping the app from the start menu onto the Desktop.

I already start the terminal through the desktop shortcut, and that does not make it appear in the list of recently used apps unfortunately. :(

@electrofloat Try restarting your PC. Nvidia caches that list within their driver the first time you open Program Settings.

@lhecker I've read the same thing, but also refused to send in a PR. But the more I think about it the more I change my mind... As far as I know you can detect Nvidia and even query for G-Sync and this is not a workaround according to the docs but the way it is supposed to work. Remember AMD guys would benefit from this as well because G-Sync and FreeSync are interchangeable.

To be fair it's a chicken egg problem. AMD clearly can handle this situation with thier drivers, Nvidia can't. With tight schedules it's easy to say yea screw Nvidia and let them fix the Problem. One can also argue that actually the Nvidia driver is fine the software just doesn't query and provide the functionality that the user wanted.

I just think it's kinda sad that there is a way to fix the issue by implementing something someone at Microsoft already documented. And this problem doesn't only happen with the Windows Terminal but with a lot of UWP and WPF apps as well

@electrofloat You can try searching for the executable using the browser in the add menu. It can be found somewhere under C:\Program Files\WindowsApps and you may have to tweak the permissions of this folder. I also couldn't make it appear on the list.

Note that this didn't actually help in my case, and my options are to disable G-Sync in windowed mode (no thank you) or use the experimental flag (this helped).

I've also observed that sometimes this issue resolves without any intervention using the default settings.

Can confirm this isn't specific to Windows Terminal on my machine.

@SirJson tl;dr: You got it the wrong way around... Windows Terminal (WT) explicitly shouldn't render at a variable refresh rate (VRR). This isn't about how we can support G-SYNC, but rather about how we can best disable it.

WT doesn't capture mouse input like games do and should properly integrate with the window manager and the rest of the OS (cursor movement, drag & drop, etc.). It should also be energy efficient which means that running at full FPS is quite counterproductive. Chrome for instance will throttle down to not render at all if it doesn't need to. In order for WT to render at 165 FPS on my relatively beefy PC it uses up almost an entire CPU core alone on the other hand.

If your graphics driver decides that a application wants VRR it'll put the entire render pipeline (for the screen the application is visible on) into a VRR-mode. If that one, single application draws at a low FPS, your entire screen will draw at that FPS, including the window manager, your mouse cursor, etc. - everything basically! This is the primary reason why VRR is only enabled for fullscreen application, or applications that capture the mouse cursor like games do. Nvidia's heuristic works for almost all regular applications. Regular .exe like Firefox, Chrome, VS Code are all correctly detected as non-G-SYNC. UWP apps like WT, Slack (yes even Slack!) are incorrectly detected as ones who want G-SYNC. This clearly a bug on Nvidia's side.

Lastly it's not even guaranteed that WT's DirectX renderer is fast enough to provide those >120 FPS you're looking for.
If it ever fails to do so, your entire screen will feel sluggish due to the above reason.

In summary, WT shouldn't render with VRR and if anyone has an idea how to make Nvidia's driver detect WT as an application that wants G-SYNC, please let me know and I'll implement it! I know it's possible somehow, because, again, UWP Minecraft is one of the very few UWP applications which are detected correctly as non-G-SYNC.

What puzzles me coming from a game developer background, and sorry if this is a stupid question, why is application loop tied to the renderer? In a game no one would do this even long before we had G-Sync cause if a system can't handle one heavy scene for example the internal logic should continue without even tho the rendering is slow.

When I then think about how it even makes the cursor choppy I wonder what is happening in the background cause with my mental model the OS cursor was a separate thing from the graphics application running. It's almost like G-Sync is slowing the whole compositor down.

But I digress just telling G-Sync to shut up is also a solution, it's not like it would have a place inside a terminal anyways. But how to do that from application code I don't know.

@SirJson I believe there are still quite a few places left for optimization in the renderer. But you need to consider that games aren't designed to be energy efficient, which is why they get away with using, let's say, 10% of your potential CPU power at all times. As a terminal this shouldn't be the case of course, which is why we'd like to to throttle the rendering loop as much as possible.
The reason your mouse cursor gets choppy is because WT is recognized as a VRR application and your display frame rate gets synchronized with WT's. Now if WT renders in an energy efficient way (meaning: seldom / if needed) WT's frame rate drops down to around 3-4 FPS, which causes your entire display's frame rate to drop to 3-4 FPS.

Yea I agree, would be stupid to render the same text 144 times just because we can.

Regarding the G-Sync exceptions I assume that's hard coded in the driver. When I open my profiles in the NVIDIA Control Panel I see automatic profiles for Chrome, Firefox.. etc and they are all correctly setup like people are doing it here manually. That would mean until someone over there wakes up and builds a profile into the driver or actually fixes G-Sync there is not much we can do.

I'm curious now what happens with AMD on the same monitor and system. After all there is a reason why I'm running this GPU setup and if Windows insists on installing the AMD drivers again again and again I might as well test this now. I wonder if AMD even allows FreeSync in Windowed Applications..

Did anyone find a way to add it to the list of apps in Nvidia Control panel?

Doesn't come up at all for me :/

Yeah, click Add -> Browse and go to C:\Program Files\WindowsApps\ There should be a folder called something like Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe.

The exe is inside.

This method is better though: https://github.com/microsoft/terminal/issues/649#issuecomment-647617350

@SirJson: Yea I agree, would be stupid to render the same text 144 times just because we can.

A high frame rate may be required if the same text can suddenly move, I don't know if a modern monitor can instantly change the frame rate to the required frame rate to move text smoothly like in applications like this (use WSL profile to enable mouse tracking) :

ssh [email protected]

netxs-group/VTM#9 With this application, you can test terminal performance by manipulating text content with your mouse using any frame rate.

Yeah, click Add -> Browse and go to C:\Program Files\WindowsApps\ There should be a folder called something like Microsoft.WindowsTerminal_1.0.1811.0_x64__8wekyb3d8bbwe.

The exe is inside.

This method is better though: #649 (comment)

Yeah, using that one for now. I tried making a profile via that method, but it doesn't work.
So SW rendering it is for now.

I also had trouble with setting an Nvidia profile for my UWP app. I installed Terminal via scoop, and _still_ couldn't get it to apply a profile. In the end I used https://github.com/Orbmu2k/nvidiaProfileInspector as suggsted by @krage and made sure the profile was nice and simple: re-did the association to windowsterminal.exe, and only modified one value, the G-Sync Application State one

Et voila! 155Hz Terminal 😎

@jalada Sorry but that method is also not working for me :(. Looks like using software rendering is the only option. I'm using The preview version of terminal btw.

After a long period and giving nVidia my msinfo32 report they are saying that they are looking into it.

Hello Kruno,

Thank you. We are looking into the issue. No further updates at this time.

Regards,
Josh
NVCC

Now we play the waiting game.

@o-sdn-o But that's a benchmark if I understand it correctly and not your typical use case. I try to see it from a practical perspective and I use a 144hz monitor daily. And tbh I have yet to find a terminal application requiring 144 FPS that is not a demo or cool effect.

The problem I see is if I want to play a game in windowed mode or new recommended "fullscreen windowed mode" but also use G-Sync without breaking Windows at the same time. Remember this is not only happening with the Windows Terminal but also for example in Microsoft Whiteboard and other UWP apps.

What confused me was the that the cursor of all things gets detected as "variable refresh rate application". To me all of that sounds like something Nvidia should look into.

Worst case, fork it, unlock the frame rate and do what ever you need to do. But it wouldn't solve the system wide issue.

Yeah, I agree entirely with @SirJson, Nvidia needs to fix their drivers by excluding this App.
It's not really a problem that originates from Windows Terminal.

I feel like I need to clarify again, that G-Sync is Nvidia's implementation of a "variable refresh rate" (VRR) for your monitor.
The important bit here is _"your monitor"_, because the refresh rate is not per application. If any application causes G-Sync to be enabled, that entire monitor will now render at the speed of the G-Sync-causing application.
Your cursor doesn't stutters when using UWP apps with G-Sync because the cursor is being detected as a VRR application, but rather because your entire monitors' refresh rate has been dynamically lowered. The reason for this is that desktop applications - like Windows Terminal - almost always only draw when necessary, which results in a low application frame rate, which G-Sync finally turns into a low refresh rate of your monitor.

Well that makes that whole feature pointless doesn't it? I assumed what my monitor is reporting, the constant 144hz, is the refresh rate of the display as a whole and trough maybe tricks with the compositor they implemented this feature.

Lucky if I have time for gaming, that one game I'm playing right now supports true full screen, I didn't touch this option for months now because of "what happens" and had zero issues with it. To be honest originally I stumbled upon this issue because my old display can be also forced to do g-sync @ 60hz (which is even more point less but hey I was curious what would happen)

To anyone having issues and don't want to use software rendering I can only recommend that you do what I and others did more than 130 days ago and hope that NVIDIA will find a solution cause the push away from true full screen is pretty clear.

Thanks @lhecker for clearing things up, for me at least

Adding "experimental.rendering.software": true also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).

This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.

This fixes the issue for me using 2080ti and several 165hz GSynced displays

Adding "experimental.rendering.software": true also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).
This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.

This fixes the issue for me using 2080ti and several 165hz GSynced displays

This also resolves the issue for me with 1080ti and 165hz GSync.

Adding "experimental.rendering.software": true also helped me. Running Windows Terminal 1.0.1401.0 using GTX 970 (Nvidia driver 432.00).
This issue isn't specific to Windows Terminal. I also had to set an experimental flag for Ableton Live and disable hardware acceleration for Spotify.

This fixes the issue for me using 2080ti and several 165hz GSynced displays

This also resolves the issue for me with 1080ti and 165hz GSync.

This resolves the issue for me on a RTX 2070 and 144hz GSync

Same thing is happening on a GeForce 2080 Ti with driver 451.67. Just what is Windows Terminal doing differently to other terminal applications with its screen rendering? Powershell, Powershell ISE, the default Windows command line, Cmder all do not exhibit this strange behavior and are fine with Gsync window or windowed settings.

I'd like to again mention my comments above as they explain the situation in detail.
This comment in particular should be the most concise: https://github.com/microsoft/terminal/issues/649#issuecomment-647777960

I'd like to again mention my comments above as they explain the situation in detail.
This comment in particular should be the most concise: #649 (comment)

I understand the reasoning in your comment if we were talking about the difference between how games capture mouse input vs other application types but I'm wondering why other terminal applications I mention seem to handle mouse input under a Gsync-enabled screen refresh rate without issue. These are standard applications and I'm sure they do not have a custom Nvidia Control Panel profile for them. What is the difference in how Windows Terminal is handling display rendering and can it be fixed by the devs, do Nvidia need to handle this or both of them?

@Seefer You're misunderstanding... G-Sync works by throttling your monitor's refresh rate and not the frame rate of your cursor.
Windows Terminal (WT) exhibits this behavior as it renders the shell using your GPU and not CPU, unlike the other terminals you tried. Nvidia incorrectly recognizes WT as an application that wants G-Sync. You can read more about this in my other comments in this issue and in the comment I linked above.

I know this sounds very rude, but as non-native english speaker and a lack of better words: Many commenters here appear to me as if they actually are very unaware what G-Sync is and how it works. I _strongly_ suggest to everyone here to turn off G-Sync for windowed applications. You should consider that Nvidia feature a very low-level, expert-only knob that should better be left on default (namely disabled). The Nvidia control panel settings should look like this:

There are only very rare circumstances in which you'd want it to be enabled. Basically the only case in which you'd want to change this setting is if you have windowed (non-fullscreen) games or other graphical applications that don't run at your monitors native refresh rate (144Hz, 240Hz, etc.).

I see your point now. Sadly, the Gsync full screen or windowed mode setting option is not really an option for me as a gamer. I run games mainly in borderless full screen wherever possible as this avoids loss-of-graphics-device issues for games that don't handle ALT-TAB very well. It's also easier to drop back to the desktop if a game crashes in order to fire up Task Manager or Process Explorer in order to End Task the frozen game. I think I'll be sticking with Cmder for my terminal needs until Windows Terminal mouse behavior is solved :(

@Seefer G-Sync's benefit is the removal of screen tearing if your application/game's framerate cannot keep up with your monitor. And technically windowed (even fullscreen windowed) applications cannot have screen tearing as they're first being composited by DWM before being shown on your monitor. So I'm personally wondering which game requires G-Sync in windowed mode... 🤔

@lhecker I don't know why exactly, but G-Sync in windowed (borderless fullscreen) mode absolutely makes a visible difference for me so I keep it on. Without it, variable refresh rate doesn't work properly (I've tried several things) and I think the framerate gets clamped by either Windows or Nvidia drivers. This is the case in all games I've played recently. I have two G-Sync monitors so I prefer using borderless fullscreen.

I remember reading that previously, games would only get exclusive access to the driver if they were in fullscreen mode but a few years ago borderless fullscreen also started giving games exclusive access with the benefit of being able to use multi-monitor setups with ease.

I should also mention that this happens even when the mouse is not over the terminal as long as the focus is set on the terminal. If I have the terminal taking up have the screen and selected then the mouse will lag anywhere I move it. Take the focus off and everything is perfect.

@jalada @SirJson and others, you just have to override it "the right way". For Store/UWP stuff, you need to use the internal name <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>. There is no need to mess with C:\Program Files\WindowsApps permissions.

Save as file with .nip ending, import file with NVIDIA Profile Inspector:

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfProfile>
  <Profile>
    <ProfileName>Windows Terminal Gsync Fix</ProfileName>
    <Executeables>
      <string>windowsterminal.exe</string>
      <string>c:/program files/windowsapps/microsoft.windowsterminal_1.1.2021.0_x64__8wekyb3d8bbwe/windowsterminal.exe</string>
      <string>Microsoft.WindowsTerminal_1.1.2021.0_x64__8wekyb3d8bbwe</string>
      <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>
    </Executeables>
    <Settings>
      <ProfileSetting>
        <SettingNameInfo>G-SYNC</SettingNameInfo>
        <SettingID>279476687</SettingID>
        <SettingValue>1</SettingValue>
        <ValueType>Dword</ValueType>
      </ProfileSetting>
    </Settings>
  </Profile>
</ArrayOfProfile>

Or unzip from this:
Nvidia-Terminal.zip

Only <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string> is necessary for a Store install (on my PC/Win/driver; can't test other configs, so I left whatever else seemed _somewhat_ reasonable).

I didn't know how NV would name such a profile (they have inconsistent Microsoft ... / Windows ... naming) and don't know what happens to this custom one if a future driver ships their own.

[on my previous driver 445.78 the Start Menu was also behaving like this half the time, ~32 Hz refresh rate; fixed in newer drivers like 451.85]

@jalada @SirJson and others, you just have to override it "the right way". For Store/UWP stuff, you need to use the internal name <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>

Save as file with .nip ending, import file with NVIDIA Profile Inspector:

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfProfile>
  <Profile>
    <ProfileName>Windows Terminal Gsync Fix</ProfileName>
    <Executeables>
      <string>windowsterminal.exe</string>
      <string>c:/program files/windowsapps/microsoft.windowsterminal_1.1.2021.0_x64__8wekyb3d8bbwe/windowsterminal.exe</string>
      <string>Microsoft.WindowsTerminal_1.1.2021.0_x64__8wekyb3d8bbwe</string>
      <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>
    </Executeables>
    <Settings>
      <ProfileSetting>
        <SettingNameInfo>G-SYNC</SettingNameInfo>
        <SettingID>279476687</SettingID>
        <SettingValue>1</SettingValue>
        <ValueType>Dword</ValueType>
      </ProfileSetting>
    </Settings>
  </Profile>
</ArrayOfProfile>

Or unzip from this:
Nvidia-Terminal.zip

Only <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string> is necessary for a Store install.

I didn't know how NV would name such a profile (they have inconsistent Microsoft ... / Windows ... naming) and don't know what happens to this custom one if a future driver ships their own.

[on my previous driver 445.78 the Start Menu was also behaving like this half the time, ~32 Hz refresh rate]

Thanks for that. Great tool. I was unaware there were so many other Nvidia profile settings hidden away. I had already added the Windows Terminal executable to Nvidia profiles but no messing around with the GSYNC settings exposed in there allowed me to adjust Windows Terminal mouse capture behaviour.

It does not seem to dynamically change my Global GSYNC Mode from Windowed or Fullscreen to Fullscreen on a per profile basis. Using Nvidia Control Panel to set GSYNC Mode to Fullscreen,, Windows Terminal mouse problems do indeed go away but if using this Profile Inspector tool to set GSYNC Mode to Fullscreen and then run Windows Terminal, mouse problems remain as though the profile setting is not able to override the Global setting. This is all very frustrating with no clear idea which party needs to make the fix (Nvidia or WT devs). Until this is resolved I'm sticking with Cmder, which is a pity because I totally dig how WT makes using WSL2 a little bit nicer :(

@jalada @SirJson and others, you just have to override it "the right way". For Store/UWP stuff, you need to use the internal name <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>
Save as file with .nip ending, import file with NVIDIA Profile Inspector:

<?xml version="1.0" encoding="utf-16"?>
<ArrayOfProfile>
  <Profile>
    <ProfileName>Windows Terminal Gsync Fix</ProfileName>
    <Executeables>
      <string>windowsterminal.exe</string>
      <string>c:/program files/windowsapps/microsoft.windowsterminal_1.1.2021.0_x64__8wekyb3d8bbwe/windowsterminal.exe</string>
      <string>Microsoft.WindowsTerminal_1.1.2021.0_x64__8wekyb3d8bbwe</string>
      <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string>
    </Executeables>
    <Settings>
      <ProfileSetting>
        <SettingNameInfo>G-SYNC</SettingNameInfo>
        <SettingID>279476687</SettingID>
        <SettingValue>1</SettingValue>
        <ValueType>Dword</ValueType>
      </ProfileSetting>
    </Settings>
  </Profile>
</ArrayOfProfile>

Or unzip from this:
Nvidia-Terminal.zip
Only <string>Microsoft.WindowsTerminal_8wekyb3d8bbwe</string> is necessary for a Store install.
I didn't know how NV would name such a profile (they have inconsistent Microsoft ... / Windows ... naming) and don't know what happens to this custom one if a future driver ships their own.
[on my previous driver 445.78 the Start Menu was also behaving like this half the time, ~32 Hz refresh rate]

Thanks for that. Great tool. I was unaware there were so many other Nvidia profile settings hidden away. I had already added the Windows Terminal executable to Nvidia profiles but no messing around with the GSYNC settings exposed in there allowed me to adjust Windows Terminal mouse capture behaviour.

It does not seem to dynamically change my Global GSYNC Mode from Windowed or Fullscreen to Fullscreen on a per profile basis. Using Nvidia Control Panel to set GSYNC Mode to Fullscreen,, Windows Terminal mouse problems do indeed go away but if using this Profile Inspector tool to set GSYNC Mode to Fullscreen and then run Windows Terminal, mouse problems remain as though the profile setting is not able to override the Global setting. This is all very frustrating with no clear idea which party needs to make the fix (Nvidia or WT devs). Until this is resolved I'm sticking with Cmder, which is a pity because I totally dig how WT makes using WSL2 a little bit nicer :(

Ok it seems to be working. I had to Remove my previous WT Profile in Control Panel and just use your .nip file to import using Nvidia Profile Inspector. I assumed because I already had a WT profile, importing yours was not necessary to get access to the WT executable profile settings. Things seem to work fine now. I can leave my Global GSYNC Mode to windowed or full screen and your profile takes care of adjusting GSYNC Mode to Full screen only when I launch WT.

Many thanks!

@Seefer G-Sync's benefit is the removal of screen tearing if your application/game's framerate cannot keep up with your monitor. And technically windowed (even fullscreen windowed) applications cannot have screen tearing as they're first being composited by DWM before being shown on your monitor. So I'm personally wondering which game requires G-Sync in windowed mode... 🤔

Any game that you run in 'borderless window' mode is basically a windowed game, just without any of the Windows OS chrome. This mode has been around for ages. I remember using it during my time programming in WIN32.

@Seefer Which is exactly why I personally haven't entirely grasped why some people require G-Sync for non-exclusive fullscreen applications. There can't be a significant benefit, since everything that G-Sync provides is something that DWM does about as well. (Given that you didn't forget to enable V-Sync.)

Either way, what needs to happen is for Nvidia to fix it on their side. They should only enable G-Sync for fullscreen windowed applications that also hide the cursor and not all regular windowed applications.

@Seefer Which is exactly why I personally haven't entirely grasped why some people require G-Sync for non-exclusive fullscreen applications. There can't be a significant benefit, since everything that G-Sync provides is something that DWM does about as well. (Given that you didn't forget to enable V-Sync.)

This is getting wildly off-topic now, but for example:
Overwatch, shows that, no, with G-SYNC enabled, both borderless and windowed mode do not add 1 frame of delay over exclusive fullscreen. Standalone “V-SYNC,” however, does show the expected 1 frame of delay. source

They should only enable G-Sync for fullscreen windowed applications that also hide the cursor and not all regular windowed applications.

Surely there could be both games that don't hide the cursor and non-games that do? Apologies if I misunderstand you, but when my media player hides the cursor it doesn't become a game, and I suppose a game can keep showing the Windows cursor as well.

@Luckz You realize that I posted the solution months ago, but then wasn't sure if it's also fixable on application level because I simply didn't remember how G-Sync exactly works. These days you can turn it on even on your toaster which makes it easy to forget what that option actually means. So that's my bad, but back then, when I posted the solution, I also mentioned how silly it was to enable windowed G-Sync in the first place. I can also note that I didn't have had a single issue since then.

After that all discussion from me was about seeking a solution that wasn't: "We wait until Nvidia notices this." But that's the only option for a real fix and software rendering is a workaround until then.

I know you didn't mean anything bad, but only because you see a name often that doesn't mean that User is also having the biggest issue.

@Luckz I agree we're drifting a bit off and I believe I'm kinda to blame for that. Sorry. 😅

But I expected that article to be mentioned, especially since it's factually wrong, or at least quite misleading. I mean it's not like that article has been peer reviewed right? So please allow me one last time to explain how the author of that article is misinterpreting their own results.
The application frame rate is virtually capped to 142 FPS, despite V-Sync being used, which would cap the framerate to 144 FPS anyways. tl;dr: Don't cap frame rates if you use V-Sync.
The author of your article did just that mistake, incorrectly making them (and you believe) that you regularly/always get a 1 frame delay, which couldn't be further from the truth. In fact only 2 out of every 144 frames are getting delayed due to this "misalignment" of application frame rate and monitor refresh rate.
A proper comparison can be seen here (you need to switch the first image over to the 144+ Hz versions). For comparison of the 0-2ms difference: An expensive, modern 144Hz monitor usually has a measured GtG response time of about 4ms and I doubt many ever noticed that. 😄

Thanks @Luckz for a fix/workaround.

I would add to the symptoms that I had experienced before putting it together that it was Windows Terminal causing it.
Running Windows 10 20H2 (OS Build 19042.450) I have seen the GSYNC monitor go to black and not turn on again (reboot required). Also seen flashing black screen across all 3 monitors. Once I applied the fix issues seems to be gone.

Hey everyone,
I've been having the same problem.
I thought my laptop was the one with the issue at first but then I noticed the problem was also occurring on certain types of applications notably Windows Store applications. I've noticed it to occur Splashable, WhatsApp, Windows Terminal, Speedtest among many others.
My laptop is the ASUS ROG Zephyrus Duo 15 GX550LWS
Specs here
My external monitor is the ASUS VG278QR (GSYNC Compatible) Gaming Monitor running @ 165Hz

Setting GSYNC to Fullscreen mode, which is ridiculous, does solve the problem though.
Also, since my GPU is Max-Q design I have the option of switching between optimus mode and discrete graphics mode. In discrete graphics mode focusing on said applications, causes my laptops second screen to go black unless their's mouse movement or something in the application is changing. I assume this is to do with rendering frames.

Splashable, WhatsApp, Speedtest among many others.

You're welcome to create profiles for all of those and send them to Nvidia ideally for inclusion in a future driver release.

I hate to pile on to an old issue, but I'm seeing that the usual fix (adding a custom profile with "Monitor Technology" set to "Fixed Refresh") is not actually working. I have an LG 38GL950G ultrawide monitor set to 100Hz. It has a hardware refresh rate display that can be turned on. Even with a profile set to disable GSync for the app, it still drops to as low as 12FPS when the Terminal is the foreground app.

Turning off G-Sync for windowed apps isn't an option, as I frequently play windowed games. This would solve this behavior, but has too many negative side effects.

Are you guys doing something different with profiles to get it to work?

Splashable, WhatsApp, Speedtest among many others.

You're welcome to create profiles for all of those and send them to Nvidia ideally for inclusion in a future driver release.

This issue needs to be upstreamed to Microsoft as it seems to be a fundamental issue with the way the UWP technology handles window draws, hopefully it can be fixed in the next Windows build. None of my non-UWP programs experience this weird behavior.

Even with a profile set to disable GSync for the app

Are you sure you got the right app? Perhaps paste what you're using as the app. (after checking a few posts above to see what usually works)

Even with a profile set to disable GSync for the app

Are you sure you got the right app? Perhaps paste what you're using as the app. (after checking a few posts above to see what usually works)

I'm using c:\program files\windowsapps\microsoft.windowsterminal_1.3.2651.0_x64__8wekyb3d8bbwe\windowsterminal.exe as the program, which is the path to the executable image as per Task Manager. I also tried WT.EXE in the same folder.

So I tried setting GSync to Fullscreen only like suggested above, but that didn't help. I outright disabled Gysnc on my machine, and if fixed the mouse flicker (low refresh rate) but when moving the window around, it is still a laggy mess (with no GSync).

What other options can I attempt?

Are you sure you got the right app? Perhaps paste what you're using as the app. (after checking a few posts above to see what usually works)

I'm using c:\program files\windowsapps\microsoft.windowsterminal_1.3.2651.0_x64__8wekyb3d8bbwe\windowsterminal.exe as the program, which is the path to the executable image as per Task Manager. I also tried WT.EXE in the same folder.

That's exactly why I asked. You have to use Microsoft.WindowsTerminal_8wekyb3d8bbwe. I uploaded a profile above (with too many other variants that aren't needed). Here's the minimum:
Nvidia-Terminal.zip

Apply with https://github.com/Orbmu2k/nvidiaProfileInspector/releases (scoop: scoop install nvidia-profile-inspector). Click the import button in the toolbar, feed it the .nip(s), and you're good to go.

some more apps with issues that I created a few profiles for:
One Note: Microsoft.Office.OneNote_8wekyb3d8bbwe
Paint 3D Microsoft.MSPaint_8wekyb3d8bbwe
Snip & Sketch Microsoft.ScreenSketch_8wekyb3d8bbwe
Xbox Accessories Microsoft.XboxDevices_8wekyb3d8bbwe
Camera (requires overriding existing Nvidia profile)
Cortana / Search UI (requires overriding existing Nvidia profile)
Feedback Hub Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe
Microsoft To Do Microsoft.Todos_8wekyb3d8bbwe

third party:
Amazon: Amazon.com.Amazon_343d40qqvtj1t
Amazon Prime Video for Windows: AmazonVideo.PrimeVideo_pwbj9vvecjh7j
Liberty Global Horizon Go: LibertyGlobal.HorizonGODE_gmwgfebrpy77e
my current 12 profile collection: Nvidia-UWP-NoGsync-Profiles.zip

But there are countless more (Mixed Reality Portal, 3D Viewer, ...)

Also keeping this issue alive/recap. Best fix so far on Windows Terminal Version 1.3.2651.0 (installed w/ choco) is "experimental.rendering.software": true in settings.json.

Downside: Cannot have a game and Windows Terminal window on the Gsync monitor, as Windows Terminal is still treated as a game.

Upside: As Windows Terminal is installed via Microsoft Store, you cannot easily apply the Nvidia Control Panel fix unless using third party nvidiaProfileInsepctor.