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

[PR #5345] [MERGED] Adjusts High DPI scaling to enable differential rendering #26269

New Issue
Open
opened 2026-01-31 09:15:03 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:15:03 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/microsoft/terminal/pull/5345
Author: @miniksa
Created: 4/13/2020
Status: ✅ Merged
Merged: 4/22/2020
Merged by: @miniksa

Base: master ← Head: dev/miniksa/dpi

📝 Commits (10+)

  • 7e8f039 Start moving dx renderer onto bitmap.
  • b46b5d0 it works!
  • 78c1bc1 try to get present1 working and get mad because std::vector is bad.
  • 39d67e3 Merge branch 'master' into dev/miniksa/dx_bitmap
  • 777524a Change invalidation to full rows to restore ligature drawing.
  • a15af9b Add tests for til and round out the operators.
  • ac01c0b code format
  • c478983 code format and audit mode.
  • f39b352 Dustin's suggestion about helper for invalidating rectangles .
  • 0d863c2 Fix selection issues.

📊 Changes

17 files changed (+356 additions, -166 deletions)

View changed files

📝 src/cascadia/PublicTerminalCore/HwndTerminal.cpp (+1 -1)
📝 src/cascadia/TerminalControl/TSFInputControl.cpp (+47 -30)
📝 src/cascadia/TerminalControl/TermControl.cpp (+130 -54)
📝 src/cascadia/TerminalControl/TermControl.h (+1 -0)
📝 src/host/screenInfo.cpp (+14 -0)
📝 src/inc/til/bitmap.h (+5 -23)
📝 src/inc/til/point.h (+13 -2)
📝 src/inc/til/rectangle.h (+12 -0)
📝 src/inc/til/size.h (+23 -3)
📝 src/renderer/dx/DxRenderer.cpp (+19 -25)
📝 src/renderer/dx/DxRenderer.hpp (+1 -0)
📝 src/til/precomp.h (+32 -0)
📝 src/til/ut_til/BitmapTests.cpp (+0 -23)
📝 src/til/ut_til/PointTests.cpp (+7 -0)
📝 src/til/ut_til/RectangleTests.cpp (+17 -0)
📝 src/til/ut_til/SizeTests.cpp (+27 -0)
📝 src/types/TermControlUiaTextRange.cpp (+7 -5)

📄 Description

Summary of the Pull Request

  • Adjusts scaling practices in DxEngine (and related scaling practices in TerminalControl) for pixel-perfect row baselines and spacing at High DPI such that differential row-by-row rendering can be applied at High DPI.

References

PR Checklist

Detailed Description of the Pull Request / Additional comments

WAS:

  • We were using implicit DPI scaling on the ID2D1RenderTarget and running all of our processing in DIPs (Device-Independent Pixels). That's all well and good for getting things bootstrapped quickly, but it leaves the actual scaling of the draw commands up to the discretion of the rendering target.
  • When we don't get to explicitly choose exactly how many pixels tall/wide and our X/Y placement perfectly, the nature of floating point multiplication and division required to do the presentation can cause us to drift off slightly out of our control depending on what the final display resolution actually is.
  • Differential drawing cannot work unless we can know the exact integer pixels that need to be copied/moved/preserved/replaced between frames to give to the IDXGISwapChain1::Present1 method. If things spill into fractional pixels or the sizes of rows/columns vary as they are rounded up and down implicitly, then we cannot do the differential rendering.

NOW:

  • When deciding on a font, the DxEngine will take the scale factor into account and adjust the proposed height of the requested font. Then the remainder of the existing code that adjusts the baseline and integer-ifies each character cell will run naturally from there. That code already works correctly to align the height at normal DPI and scale out the font heights and advances to take an exact integer of pixels.
  • TermControl has to use the scale now, in some places, and stop scaling in other places. This has to do with how the target's nature used to be implicit and is now explicit. For instance, determining where the cursor click hits must be scaled now. And determining the pixel size of the display canvas must no longer be scaled.
  • DxEngine will no longer attempt to scale the invalid regions per my attempts in #5185 because the cell size is scaled. So it should work the same as at 96 DPI.
  • The block is removed from the DxEngine that was causing a full invalidate on every frame at High DPI.
  • A TODO was removed from TermControl that was invalidating everything when the DPI changed because the underlying renderer will already do that.

Validation Steps Performed

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/microsoft/terminal/pull/5345 **Author:** [@miniksa](https://github.com/miniksa) **Created:** 4/13/2020 **Status:** ✅ Merged **Merged:** 4/22/2020 **Merged by:** [@miniksa](https://github.com/miniksa) **Base:** `master` ← **Head:** `dev/miniksa/dpi` --- ### 📝 Commits (10+) - [`7e8f039`](https://github.com/microsoft/terminal/commit/7e8f0398c3c851c96189b1ef72f1c82feda7510e) Start moving dx renderer onto bitmap. - [`b46b5d0`](https://github.com/microsoft/terminal/commit/b46b5d0f6f0e09ce874c9a1097f7c24dc5cd6c85) it works! - [`78c1bc1`](https://github.com/microsoft/terminal/commit/78c1bc10f7680f3ada2e3ccdf317322e550afdcb) try to get present1 working and get mad because std::vector<bool> is bad. - [`39d67e3`](https://github.com/microsoft/terminal/commit/39d67e3859f9fac479212d5cb7dfce32269aaf3a) Merge branch 'master' into dev/miniksa/dx_bitmap - [`777524a`](https://github.com/microsoft/terminal/commit/777524a00f80c532ed45af2a022bb163a1923a1d) Change invalidation to full rows to restore ligature drawing. - [`a15af9b`](https://github.com/microsoft/terminal/commit/a15af9b3fd7c023fd380eb76b6dd2cdc34df63c0) Add tests for til and round out the operators. - [`ac01c0b`](https://github.com/microsoft/terminal/commit/ac01c0bd8f5e3b8f2d4aa39639d25cfa72119002) code format - [`c478983`](https://github.com/microsoft/terminal/commit/c4789836d5ae26bae5375fad37a3043f9913afe5) code format and audit mode. - [`f39b352`](https://github.com/microsoft/terminal/commit/f39b352b608ad854bf689d9e7e2ae77e7a4fbb7a) Dustin's suggestion about helper for invalidating rectangles . - [`0d863c2`](https://github.com/microsoft/terminal/commit/0d863c2ed190969b1eb56707030e10e17c711206) Fix selection issues. ### 📊 Changes **17 files changed** (+356 additions, -166 deletions) <details> <summary>View changed files</summary> 📝 `src/cascadia/PublicTerminalCore/HwndTerminal.cpp` (+1 -1) 📝 `src/cascadia/TerminalControl/TSFInputControl.cpp` (+47 -30) 📝 `src/cascadia/TerminalControl/TermControl.cpp` (+130 -54) 📝 `src/cascadia/TerminalControl/TermControl.h` (+1 -0) 📝 `src/host/screenInfo.cpp` (+14 -0) 📝 `src/inc/til/bitmap.h` (+5 -23) 📝 `src/inc/til/point.h` (+13 -2) 📝 `src/inc/til/rectangle.h` (+12 -0) 📝 `src/inc/til/size.h` (+23 -3) 📝 `src/renderer/dx/DxRenderer.cpp` (+19 -25) 📝 `src/renderer/dx/DxRenderer.hpp` (+1 -0) 📝 `src/til/precomp.h` (+32 -0) 📝 `src/til/ut_til/BitmapTests.cpp` (+0 -23) 📝 `src/til/ut_til/PointTests.cpp` (+7 -0) 📝 `src/til/ut_til/RectangleTests.cpp` (+17 -0) 📝 `src/til/ut_til/SizeTests.cpp` (+27 -0) 📝 `src/types/TermControlUiaTextRange.cpp` (+7 -5) </details> ### 📄 Description ## Summary of the Pull Request - Adjusts scaling practices in `DxEngine` (and related scaling practices in `TerminalControl`) for pixel-perfect row baselines and spacing at High DPI such that differential row-by-row rendering can be applied at High DPI. ## References - #5185 ## PR Checklist * [x] Closes #5320, closes #3515, closes #1064 * [x] I work here. * [x] Manually tested. * [x] No doc. * [x] Am core contributor. Also discussed with some of them already via Teams. ## Detailed Description of the Pull Request / Additional comments **WAS:** - We were using implicit DPI scaling on the `ID2D1RenderTarget` and running all of our processing in DIPs (Device-Independent Pixels). That's all well and good for getting things bootstrapped quickly, but it leaves the actual scaling of the draw commands up to the discretion of the rendering target. - When we don't get to explicitly choose exactly how many pixels tall/wide and our X/Y placement perfectly, the nature of floating point multiplication and division required to do the presentation can cause us to drift off slightly out of our control depending on what the final display resolution actually is. - Differential drawing cannot work unless we can know the exact integer pixels that need to be copied/moved/preserved/replaced between frames to give to the `IDXGISwapChain1::Present1` method. If things spill into fractional pixels or the sizes of rows/columns vary as they are rounded up and down implicitly, then we cannot do the differential rendering. **NOW:** - When deciding on a font, the `DxEngine` will take the scale factor into account and adjust the proposed height of the requested font. Then the remainder of the existing code that adjusts the baseline and integer-ifies each character cell will run naturally from there. That code already works correctly to align the height at normal DPI and scale out the font heights and advances to take an exact integer of pixels. - `TermControl` has to use the scale now, in some places, and stop scaling in other places. This has to do with how the target's nature used to be implicit and is now explicit. For instance, determining where the cursor click hits must be scaled now. And determining the pixel size of the display canvas must no longer be scaled. - `DxEngine` will no longer attempt to scale the invalid regions per my attempts in #5185 because the cell size is scaled. So it should work the same as at 96 DPI. - The block is removed from the `DxEngine` that was causing a full invalidate on every frame at High DPI. - A TODO was removed from `TermControl` that was invalidating everything when the DPI changed because the underlying renderer will already do that. ## Validation Steps Performed * [x] Check at 150% DPI. Print text, scroll text down and up, do selection. * [x] Check at 100% DPI. Print text, scroll text down and up, do selection. * [x] Span two different DPI monitors and drag between them. * [x] Giant pile of tests in https://github.com/microsoft/terminal/pull/5345#issuecomment-614127648 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-31 09:15:03 +00:00
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 pull-request
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#26269
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?