Windows: Improve DPI scaling on modern OS versions - #19387
Open
Ryunam wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
In the current RetroArch master on Windows, the DPI metrics used for scaling widgets and UI elements for certain menu drivers (Ozone and MaterialUI) are based on the physical size/resolution of the screen (HORZRES and HORZSIZE), calculated through the
GetDeviceCaps()function. This calculation does not take into account the user-defined DPI scaling as set in Windows itself.As a consequence of this, when using RA on a Windows device that might be connected to 2+ screens having the same resolution but different DPI values (such as in my use-case, an handheld PC with a 7-inch 1080p internal screen that is occasionally docked to a bigger 1080p screen), the UI scaling will end up differing greatly between one screen and another.
This forces users to adjust the scaling factor in the menu every single time the screen is switched around...
This PR proposes a more accurate form of DPI awareness, derived from the shcore.dll library and the
GetScaleFactorForMonitor()function. On Windows versions 8.1 and above, this lets us calculate the DPI value that was actually set for the chosen monitor in the OS, preserving the UI scale between same-res screens with different DPI values.The original GetDeviceCaps() method is kept as a fallback approach for older Windows systems, where the shcore library or the newer DPI awareness systems might not be available (Windows 7 and below).
Reviewers
@LibretroAdmin