starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Support variable refresh rate display #11142

New Issue
Closed
opened 2026-01-31 02:39:44 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 02:39:44 +00:00
Owner
Copy Link

Originally created by @dmex on GitHub (Oct 23, 2020).

The Windows Terminal is missing a flag required for variable refresh rate display support which ends up directly causing two additional bugs in the dx renderer.

7a75e508d6/src/renderer/dx/DxRenderer.cpp (L1331)

and here:
7a75e508d6/src/renderer/dx/DxRenderer.cpp (L1352)

Must to be changed from 1 to 0.

Those two changes are needed for fixing both #649 and #7147 and mentioned in the nvidia documentation:

image

Originally created by @dmex on GitHub (Oct 23, 2020). The Windows Terminal is missing a flag required for variable refresh rate display support which ends up directly causing two additional bugs in the dx renderer. * The first issue is the missing flags to enable support for variable refresh rate displays (for example 144hz monitors). This is documented on MSDN here (includes source code sample): https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/variable-refresh-rate-displays * The second issue is the terminal renderer passing 1 when calling Present() forcing vsync for the surfaces both here: https://github.com/microsoft/terminal/blob/7a75e508d6355e6a5994b8ef3aa5dca70fe7d4f1/src/renderer/dx/DxRenderer.cpp#L1331 and here: https://github.com/microsoft/terminal/blob/7a75e508d6355e6a5994b8ef3aa5dca70fe7d4f1/src/renderer/dx/DxRenderer.cpp#L1352 Must to be changed from 1 to 0. Those two changes are needed for fixing both #649 and #7147 and mentioned in the nvidia documentation: ![image](https://user-images.githubusercontent.com/1306177/96972495-4dbad400-1562-11eb-91f9-ec1b9f859c70.png)
claunia added the Issue-FeatureNeeds-TriageNeeds-Tag-Fix labels 2026-01-31 02:39:44 +00:00
claunia commented 2026-01-31 02:39:45 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2020):

I believe @lhecker tried both of these things and documented them in #649. Do you recall, Leonard?

This thread may not need to be separate from 649; comments about the behavior and why this may not be in WT’s purview start here: https://github.com/microsoft/terminal/issues/649#issuecomment-647777960

@DHowett commented on GitHub (Oct 23, 2020): I believe @lhecker tried both of these things and documented them in #649. Do you recall, Leonard? This thread may not need to be separate from 649; comments about the behavior and why this may not be in WT’s purview start here: https://github.com/microsoft/terminal/issues/649#issuecomment-647777960
claunia commented 2026-01-31 02:39:45 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Oct 23, 2020):

If you have tested and confirmed that this works, we’d love to evaluate it! 😄

@DHowett commented on GitHub (Oct 23, 2020): If you have tested and confirmed that this works, we’d love to evaluate it! 😄
claunia commented 2026-01-31 02:39:46 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 23, 2020):

There's a slight chance that I did something wrong, when I tried to implement Variable Refresh Rate (VRR) support, but I honestly doubt that, since I had full Nvidia G-Sync support locally.

But what I said in https://github.com/microsoft/terminal/issues/649#issuecomment-647777960 basically explains why VRR is the entirely wrong approach for us, a non-game application which composites with the rest of the desktop.
A VRR application controls the frame rate of the monitor. If the VRR application draws at 100 FPS, the monitor will run at 100 Hz. If the application draws at 20 FPS, well the monitor will run at 20 Hz, etc.
A monitor running at 20 Hz, will make your cursor look stuttery, the browser you have open side-by-side and so on. To prevent these unsightly side effects we'll have to draw at full speed all the time. That would fix #649, but drain laptop batteries extremely fast just by the application being open.
VRR was designed to prevent screen tearing when applications dip below the maximum refresh rate of a monitor, without having the (about) 1-frame overhead of V-Sync. This comes at the sacrifice that you cannot do on-demand rendering anymore and that applications cannot properly composite with the rest of the desktop.
Considering that most people will not run Windows Terminal (WT) in an exclusive fullscreen mode, VRR support will not be beneficial for this project. The only way it could, is if we add a VRR setting, detect VRR capable hardware and only enable VRR when WT is in an exclusive fullscreen mode (I don't know how to do the second step).

If you could tell me how to make Nvidia's drivers stop recognizing this application as one that wants G-Sync I'd gladly implement that on the other hand, because we could then finally close #649. 😄

@lhecker commented on GitHub (Oct 23, 2020): There's a slight chance that I did something wrong, when I tried to implement Variable Refresh Rate (VRR) support, but I honestly doubt that, since I had full Nvidia G-Sync support locally. But what I said in https://github.com/microsoft/terminal/issues/649#issuecomment-647777960 basically explains why VRR is the entirely wrong approach for us, a non-game application which composites with the rest of the desktop. A VRR application controls the frame rate of the monitor. If the VRR application draws at 100 FPS, the monitor will run at 100 Hz. If the application draws at 20 FPS, well the monitor will run at 20 Hz, etc. A monitor running at 20 Hz, will make your cursor look stuttery, the browser you have open side-by-side and so on. To prevent these unsightly side effects we'll have to draw at full speed all the time. That would fix #649, but drain laptop batteries extremely fast just by the application being open. VRR was designed to prevent screen tearing when applications dip below the maximum refresh rate of a monitor, without having the (about) 1-frame overhead of V-Sync. This comes at the sacrifice that you cannot do on-demand rendering anymore and that applications cannot properly composite with the rest of the desktop. Considering that most people will not run Windows Terminal (WT) in an exclusive fullscreen mode, VRR support will not be beneficial for this project. The only way it could, is if we add a VRR setting, detect VRR capable hardware and only enable VRR when WT is in an exclusive fullscreen mode (I don't know how to do the second step). If you could tell me how to make Nvidia's drivers stop recognizing this application as one that wants G-Sync I'd gladly implement that on the other hand, because we could then finally close #649. 😄
claunia commented 2026-01-31 02:39:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 23, 2020):

Thanks for the additional details @lhecker. From the sounds of this, since there's nothing else actionable here, we should probably close this thread as a dupe of #649, yea?

@zadjii-msft commented on GitHub (Oct 23, 2020): Thanks for the additional details @lhecker. From the sounds of this, since there's nothing else actionable here, we should probably close this thread as a dupe of #649, yea?
claunia commented 2026-01-31 02:39:46 +00:00
Author
Owner
Copy Link

@dmex commented on GitHub (Oct 24, 2020):

VRR support will not be beneficial for this project. The only way it could, is if we add a VRR setting

The issue affects other applications when you're using multiple monitors with Discord, Skype, Slack, Twitch, Visual Studio, Youtube etc... you can't use those screens and applications when the Terminal window has focus.

if we add a VRR setting, detect VRR capable hardware

The best solution was using "UseDx": false but there should be a setting for disabling vsync similar to games.

only enable VRR when WT is in an exclusive fullscreen mode (I don't know how to do the second step).

If it's the same with IDesktopWindowXamlSourceNative as the d3d12 samples IslandWindow::OnSize would need GetFullscreenState: https://github.com/microsoft/DirectX-Graphics-Samples/blob/master/Samples/Desktop/D3D12Fullscreen/src/D3D12Fullscreen.cpp#L636-L646

The sample passes the flag to Present() without vsync here:
https://github.com/microsoft/DirectX-Graphics-Samples/blob/master/Samples/Desktop/D3D12Fullscreen/src/D3D12Fullscreen.cpp#L568-L575

close this thread as a dupe of

Yep, we can close it 👍

@dmex commented on GitHub (Oct 24, 2020): > VRR support will not be beneficial for this project. The only way it could, is if we add a VRR setting The issue affects other applications when you're using multiple monitors with Discord, Skype, Slack, Twitch, Visual Studio, Youtube etc... you can't use those screens and applications when the Terminal window has focus. > if we add a VRR setting, detect VRR capable hardware The best solution was using ` "UseDx": false` but there should be a setting for disabling vsync similar to games. > only enable VRR when WT is in an exclusive fullscreen mode (I don't know how to do the second step). If it's the same with IDesktopWindowXamlSourceNative as the d3d12 samples IslandWindow::OnSize would need GetFullscreenState: https://github.com/microsoft/DirectX-Graphics-Samples/blob/master/Samples/Desktop/D3D12Fullscreen/src/D3D12Fullscreen.cpp#L636-L646 The sample passes the flag to Present() without vsync here: https://github.com/microsoft/DirectX-Graphics-Samples/blob/master/Samples/Desktop/D3D12Fullscreen/src/D3D12Fullscreen.cpp#L568-L575 > close this thread as a dupe of Yep, we can close it 👍
claunia commented 2026-01-31 02:39:46 +00:00
Author
Owner
Copy Link

@Luckz commented on GitHub (Oct 28, 2020):

Correct me if I'm wrong, please: wouldn't the correct fix be G-Sync being disabled for all affected MS Store apps (without affecting games)? Either via the app communicating to the driver that it is not a game and will not benefit from variable refresh rate, or the driver detecting through profiles or algorithms that this is the case.

The behaviour in that case with a 59/60 fps game (internal limiter) and a 144 Hz Windows Terminal (Nvidia profile disabling G-Sync for Terminal):
if the game is in focus, and Terminal is out of sight, the screen will be at 59/60 Hz.
With Terminal in focus, the screen will be at 144 Hz.
With both overlapping in a specific way, and the game on top, the OSD-displayed refresh rate varies wildly and seems to be around 100 Hz. A hybrid of both if you so want.

@Luckz commented on GitHub (Oct 28, 2020): Correct me if I'm wrong, please: wouldn't the _correct fix_ be G-Sync being disabled for **all** affected MS Store apps (without affecting games)? Either via the app communicating to the driver that it is _not_ a game and will _not_ benefit from variable refresh rate, or the driver detecting through profiles or algorithms that this is the case. The behaviour in that case with a 59/60 fps game (internal limiter) and a 144 Hz Windows Terminal (Nvidia profile disabling G-Sync for Terminal): if the game is in focus, and Terminal is out of sight, the screen will be at 59/60 Hz. With Terminal in focus, the screen will be at 144 Hz. With both overlapping in a specific way, and the game on top, the OSD-displayed refresh rate varies wildly and seems to be around 100 Hz. A hybrid of both if you so want.
claunia commented 2026-01-31 02:39:46 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 28, 2020):

Correct me if I'm wrong, please: wouldn't the correct fix be G-Sync being disabled for all affected MS Store apps (without affecting games)?

Yep that's exactly what I tried to convey @Luckz.
While VRR is really nice, it doesn't make a lot of sense the way it works for (non-fullscreen) windowed applications.
Nvidia synchronizes the monitor refresh rate with the frame rate of the topmost/focused application.
While that works well enough for fullscreen applications it breaks down for windowed ones. For instance if you have a Youtube video running side-by-side with Windows Terminal the video will now get displayed at 2 FPS.
What VRR drivers like Nvidia's should do instead is refresh the monitor at the highest frame rate of all visible applications.
Alternatively they should stop assuming all UWP applications want to use VRR.

@lhecker commented on GitHub (Oct 28, 2020): > Correct me if I'm wrong, please: wouldn't the correct fix be G-Sync being disabled for all affected MS Store apps (without affecting games)? Yep that's exactly what I tried to convey @Luckz. While VRR is really nice, it doesn't make a lot of sense the way it works for (non-fullscreen) windowed applications. Nvidia synchronizes the monitor refresh rate with the frame rate of the topmost/focused application. While that works well enough for fullscreen applications it breaks down for windowed ones. For instance if you have a Youtube video running side-by-side with Windows Terminal the video will now get displayed at 2 FPS. What VRR drivers like Nvidia's should do instead is refresh the monitor at the highest frame rate of all visible applications. Alternatively they should stop assuming all UWP applications want to use VRR.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Feature Needs-Tag-Fix Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11142
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?