-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GSync/Freesync refresh rate / FPS drops when using Terminal #649
Comments
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.
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 👍
…On Fri, May 10, 2019 at 4:27 PM mblowey ***@***.***> 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
<#649 (comment)>,
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: You can also download a video file with HEVC 240FPS (low bit rate) here: 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 |
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.
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. |
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. |
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 #649 (comment) I used to follow this comment #649 (comment) 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
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. |
Found this issue today when I tried to move the window with PowerShell window in focus. I too use G-Sync and 144Hz. If I switch to a settings tab, everything is fine |
When switching to my secondary 60hz monitor the problem disappears. Re-appears when Terminal is on the main gsync compatible 144hz monitor again. Powershell 7.2.3 |
FYI Nvidia has a section about G-SYNC issues in their latest driver update documentation (512.77): This issue affects Windows Terminal Preview and a future driver update will include an application profile force-disabling G-SYNC for us as a stop-gap fix. I personally have disabled G-SYNC in the meantime (as I suffer from the same issue). |
After this problem was not there for me for some time, with the latest preview build it is back (Version: 1.16.2642.0), while the current stable build does not have the problem on the same machine (Version: 1.15.2875.0). If I have both open at the same time I can see it when moving the mouse over the preview build window, when moving back to the stable build window it is gone. Very annoying. |
Any update on this? Seems to be happening since 2019 and still an issue in Windows 11 22H2 with Windows Terminal Preview |
Edit (2023-09-08): Finally figured out why it started occurring again. When NVIDIA added Windows Terminal Preview to their driver list they added |
I still get heavy stuttering with G-Sync enabled ONLY for fullscreen apps and explicitly disabled for windows terminal, on both driver versions 536.23 and 528.49, with windows terminal version 1.18.1462.0 on Windows 10. JetBrains/skiko#558 suggests it affects many other apps too so seems like something is very broken in nvidia's VRR handling. Update: applying the workaround at https://nvidia.custhelp.com/app/answers/detail/a_id/5157 and making sure g-sync is force disabled for windows terminal seems to work around it for now. |
i have been chasing this since the start of 2023, and nobody i tell the story to believes me. but the original poster i can tell feels what i feel. and i can't find a way to purposely trigger it, i just have to wait until my entire desktop surprise starts feeling like butt, and then be like "yep wt is running" close -instantly-fixed- and its not obvious! its not using stupid (or any) cpu/gpu according to task manager. it somehow just breaks it all just being. |
This is really annoying to see how this blatant issue is being ignored. If the terminal is open a GSYNC monitor here only renders at below 30Hz. Do I disable GSYNC completely it works fine. Something is off here. I know there are other applications with similar issues (Razor Synapse for me), but a terminal application HAS to work! |
@chrislu @darkconsole Just for my own curiosity, are you using Windows Terminal Preview? Edit: After testing around I found that the Nvidia driver profile for us is faulty and doesn't include the right package names. Here's how you fix it:
I'll be contacting Nvidia shortly and provide them with a fixed list. |
mine is presently the v1.17.11461.0 from the releases here that is from may. applied your updated nvidia profile. yesterday i was unable to provoke it on purpose into breaking to try and give a step to causality before posting. open-close lid, unplug-plug screen, launch-crash starfield, etc. if it doesn't happen over the weekend that will be a big step up. just have to do what i usually do until it does what it does. |
i still suffer from a different bug where it (wt itself) seems to load different profiles based on if i type anyway cheers, just gotta wait and see over here. |
@lhecker Thanks. I applied the fixed profile and now the problems with GSYNC are gone on my end. Thanks a lot! |
mine also made it the entire weekend and then some without doing the bad, after applying the nvidia profile fix. one might ponder why a terminal needs graphic drivers support, but hey. |
Is this still an issue? I had (easily reproducible) reports of this type of problem with paint.net awhile ago. It's possible for the app to use NvAPI and create its own profile so that users don't have to do it themselves. Happy to share the code I'm using in paint.net for this, it's not too difficult. |
think nvidia has shipped the fix, i've iterated over a few driver updates since then and its still working OK. |
I'm on a 27GP950-B.AUS with a 4090, issue is still present. |
Experiencing the problem as well, only since 4.2 |
Okay here's my code that solves this in Paint.NET. I toss it onto the threadpool at app start so it doesn't interfere with startup performance. It does take, IIRC, a few 10s of milliseconds. https://gist.github.com/rickbrew/10e5c0fa3593ceb6f03766914f43a0c6 |
Ahh this is a fun bug - is there an appropriate remedy here? I am not sure why this started recently. |
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 anAsus PG279Q
.The text was updated successfully, but these errors were encountered: