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

Windows Terminal no longer uses Hardware Composed: Independent Flip on primary display after Windows 24H2 update #23348

New Issue
Closed
opened 2026-01-31 08:39:42 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 08:39:42 +00:00
Owner
Copy Link

Originally created by @mickey1700 on GitHub (Jun 6, 2025).

Windows Terminal version

1.22.11141.0

Windows build number

10.0.26100.0

Other Software

OS: Windows 11 Pro, Version 10.0.26100 (24H2)

GPU: NVIDIA GeForce RTX 4070 Ti(Both displays are connected to the GPU)

Driver: Game Ready Driver 576.52 (Released: May 19, 2025)

DirectX Runtime: DirectX 12

Steps to reproduce

I've been using Windows Terminal for a while, and it previously ran in Hardware Composed: Independent Flip mode when placed on my primary display (with MPO support detected). However, after updating to Windows 11 version 24H2, the terminal window consistently runs in Composed: Flip mode, regardless of which display it's on.

If I disconnect one of the monitors - i.e., use a single-monitor setup - Windows Terminal reverts to Hardware Composed: Independent Flip as expected.

I used PresentMon and dxdiag to confirm the presentation model mode and that MPO support is present.

Is anyone else experiencing this issue in a dual-monitor setup? Could this be a known issue with the Desktop Window Manager (DWM) in 24H2, or is it related to how the Windows Terminal window is created?

Any insights or suggestions would be appreciated.

Expected Behavior

No response

Actual Behavior

I'm happy to provide reproduction steps, a screen recording, or debug logs if needed.

Originally created by @mickey1700 on GitHub (Jun 6, 2025). ### Windows Terminal version 1.22.11141.0 ### Windows build number 10.0.26100.0 ### Other Software OS: Windows 11 Pro, Version 10.0.26100 (24H2) GPU: NVIDIA GeForce RTX 4070 Ti(Both displays are connected to the GPU) Driver: Game Ready Driver 576.52 (Released: May 19, 2025) DirectX Runtime: DirectX 12 ### Steps to reproduce I've been using Windows Terminal for a while, and it previously ran in `Hardware Composed: Independent Flip` mode when placed on my primary display (with `MPO` support detected). However, after updating to Windows 11 version 24H2, the terminal window consistently runs in `Composed: Flip` mode, regardless of which display it's on. If I disconnect one of the monitors - i.e., use a single-monitor setup - Windows Terminal reverts to `Hardware Composed: Independent Flip` as expected. I used `PresentMon` and `dxdiag` to confirm the presentation model mode and that `MPO` support is present. Is anyone else experiencing this issue in a dual-monitor setup? Could this be a known issue with the Desktop Window Manager (DWM) in 24H2, or is it related to how the Windows Terminal window is created? Any insights or suggestions would be appreciated. ### Expected Behavior _No response_ ### Actual Behavior I'm happy to provide reproduction steps, a screen recording, or debug logs if needed.
claunia commented 2026-01-31 08:39:46 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 11, 2025):

This is a very in-depth observation. Before we debug too far: is it causing you a specific issue?

From a quick search, it appears as though nvidia's driver version 576 is trouble. Have you applied any workarounds because of that?

Alternative thoughts: DWM may have changed its framerate targets for using MPO. Maybe printing more text more often through Terminal will up its framerate and kick it up into another bucket where it gets assigned its own plane?

@DHowett commented on GitHub (Jun 11, 2025): This is a very in-depth observation. Before we debug too far: is it causing you a specific _issue_? --- From a quick search, it appears as though nvidia's driver version 576 is trouble. Have you applied any workarounds because of that? Alternative thoughts: DWM may have changed its framerate targets for using MPO. Maybe printing more text more often through Terminal will up its framerate and kick it up into another bucket where it gets assigned its own plane?
claunia commented 2026-01-31 08:39:47 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 11, 2025):

I was testing this on the 560 driver series and while producing output at 240Hz and it still used a composed flip model. Maybe it's a DWM update after all?

@lhecker commented on GitHub (Jun 11, 2025): I was testing this on the 560 driver series and while producing output at 240Hz and it still used a composed flip model. Maybe it's a DWM update after all?
claunia commented 2026-01-31 08:39:47 +00:00
Author
Owner
Copy Link

@mickey1700 commented on GitHub (Jun 12, 2025):

I appreciate your attention to this issue.

This is a very in-depth observation. Before we debug too far: is it causing you a specific issue?

While there's no functional malfunction, I've observed increased input latency, particularly noticeable at 60 Hz refresh rates.

From a quick search, it appears as though nvidia's driver version 576 is trouble. Have you applied any workarounds because of that?

I attempted to roll back to GeForce Game Ready Driver 566.03, but the issue persists with that version as well.

Alternative thoughts: DWM may have changed its framerate targets for using MPO. Maybe printing more text more often through Terminal will up its framerate and kick it up into another bucket where it gets assigned its own plane?

I explored the OverlayMinFPS registry setting as documented here. In my case, it's set to 0. I tried deleting and modifying this setting, but it doesn't affect the issue on Windows 11 24H2. The Windows Terminal window consistently uses the Composed: Flip presentation model mode, regardless of these changes.

@mickey1700 commented on GitHub (Jun 12, 2025): I appreciate your attention to this issue. > This is a very in-depth observation. Before we debug too far: is it causing you a specific _issue_? While there's no functional malfunction, I've observed increased input latency, particularly noticeable at 60 Hz refresh rates. > From a quick search, it appears as though nvidia's driver version 576 is trouble. Have you applied any workarounds because of that? I attempted to roll back to [GeForce Game Ready Driver 566.03](https://www.nvidia.com/en-us/drivers/details/235774/), but the issue persists with that version as well. > Alternative thoughts: DWM may have changed its framerate targets for using MPO. Maybe printing more text more often through Terminal will up its framerate and kick it up into another bucket where it gets assigned its own plane? I explored the `OverlayMinFPS` registry setting as documented [here](https://learn.microsoft.com/en-us/windows/win32/dwm/registry-values). In my case, it's set to 0. I tried deleting and modifying this setting, but it doesn't affect the issue on Windows 11 24H2. The Windows Terminal window consistently uses the `Composed: Flip` presentation model mode, regardless of these changes.
claunia commented 2026-01-31 08:39:47 +00:00
Author
Owner
Copy Link

@mickey1700 commented on GitHub (Jun 12, 2025):

I was testing this on the 560 driver series and while producing output at 240Hz and it still used a composed flip model. Maybe it's a DWM update after all?

Thanks for taking the time to confirm this - I appreciate it. It does feel like a regression in the Desktop Window Manager (DWM) to me as well.

@mickey1700 commented on GitHub (Jun 12, 2025): > I was testing this on the 560 driver series and while producing output at 240Hz and it still used a composed flip model. Maybe it's a DWM update after all? Thanks for taking the time to confirm this - I appreciate it. It does feel like a regression in the Desktop Window Manager (DWM) to me as well.
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 Area-AtlasEngine Impact-Correctness Issue-Bug Product-Terminal Tracking-External
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#23348
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?