GSync/Freesync refresh rate / FPS drops when using Terminal

[MoshiBin]

My main monitor is 144Hz. An easy way of seeing the current FPS is wiggling the mouse - the movement in 144 FPS is much smoother than 60 FPS, and this is very noticeable.

While using Terminal, the FPS constantly drops, and moves between low FPS and full 144 FPS. I can't tell if it drops to 60 FPS or a different amount, but it's way lower than 144 FPS. Wiggling the cursor while typing shows this problem well.

It seems like every interaction with the Terminal can cause the FPS to "flip" between low and high: Focusing on the window, typing, etc. Sometimes waiting ~3 seconds is enough for the FPS to switch back to high.

Graphics card is an Nvidia GTX 1080 Ti and monitor is an Asus PG279Q.

C:\WINDOWS\system32>ver

Microsoft Windows [Version 10.0.18362.86]

[zadjii-msft]

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.

[mblowey]

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.

[MoshiBin]

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 .

[RadekDevaAs]

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

[The-L3mur]

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

[SwimmingTiger]

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/

[DLSteve]

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.

[agret]

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.

[zadjii-msft]

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?

[DickyT]

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

[gralpli]

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

[miniksa]

@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.

[mblowey]

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.

[miniksa]

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.

[DickyT]

@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

[jefmes]

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. :)

[GavinHaak]

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

[SirJson]

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.

[beren12]

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.

[Seefer]

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?

[DHowett-MSFT]

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.

[SirJson]

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?

[Seefer]

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.

[miniksa]

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.

[Hoffs]

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.

[SirJson]

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?

[zackhorvath]

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

[miniksa]

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.

[zackhorvath]

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!

[miniksa]

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...

[SirJson]

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.

[Systemcluster]

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

[miniksa]

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...

[binarycrusader]

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.

[binarycrusader]

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.

[SirJson]

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.

[rennex]

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.

[miniksa]

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?

[binarycrusader]

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.

[binarycrusader]

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.

[miniksa]

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.

[TheManchineel]

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.

[zadjii-msft]

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 😕

[miniksa]

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

[rennex]

@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.

[rennex]

@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.

[krage]

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.

[ylor]

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.

[binarycrusader]

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.

[ssiloti]

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.