terminal
terminal copied to clipboard
GSync/Freesync refresh rate / FPS drops when using Terminal
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]
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.
- Open NVidia Control Panel.
- On the left, select Manage 3D Settings.
- Select the Program Settings tab.
- You will have to add the Windows Terminal app to the list of programs in the drop down.
- One of the options in the box should show G-Sync is enabled. Disable it.
- 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 [email protected] 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.
- Open NVidia Control Panel.
- On the left, select Manage 3D Settings.
- Select the Program Settings tab.
- You will have to add the Windows Terminal app to the list of programs in the drop down.
- One of the options in the box should show G-Sync is enabled. Disable it.
- 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
- follow this comment https://github.com/microsoft/terminal/issues/649#issuecomment-491288003
- reboot
- 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 modein 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...