Skip to content

Surface screen DPI and scale in GraphicsOutput#3132

Draft
Ethereal77 wants to merge 3 commits intostride3d:masterfrom
Ethereal77:feature/dpi
Draft

Surface screen DPI and scale in GraphicsOutput#3132
Ethereal77 wants to merge 3 commits intostride3d:masterfrom
Ethereal77:feature/dpi

Conversation

@Ethereal77
Copy link
Copy Markdown
Contributor

PR Details

This pull request adds support for retrieving and exposing display DPI (dots per inch) information
in the GraphicsOutput class, allowing the engine to be DPI-aware and adapt rendering to different
display scaling settings.

  • Added new properties Dpi (horizontal and vertical DPI as Int2) and DpiScale (scale factor relative to 96 DPI) to the GraphicsOutput class, providing access to the display's DPI and scaling information.
  • On initialization, GraphicsOutput now retrieves DPI information for the attached monitor using the Win32 GetDpiForMonitor API and sets the new properties accordingly.

Related Issue

#2906

Types of changes

  • Docs change / refactoring / dependency upgrade
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My change requires a change to the documentation.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have built and run the editor to try this change out.

Open questions

(I will be removing these once they are cleared/resolved)

  • Current implementation is Windows-only and Direct3D-only. No blocking issue preventing its use in Windows+Vulkan, so I'll do that next.
  • Currently using Win32 function GetDpiForMonitor, which is supported only on Windows 8.1+. If this is a problem, I can look at some alternative. Although Win8.1 is from 2013!
  • This only tells the DPI of the screen. If there is need to know the DPI affecting a window, now it can be done manually.
  • There is another API (GetDpiForWindow) that allows to get the DPI affecting a specific window and respect the per-monitor DPI awareness setting of the application, but it is Windows 10+ only. If there is interest I can implement it on GameWindow.
  • There is also a Windows message that informs applications of DPI configuration changes. Currently that message is ignored, but maybe it could be exposed as an event on GameWindow.

@Ethereal77
Copy link
Copy Markdown
Contributor Author

Current implementation is Windows-only and Direct3D-only. No blocking issue preventing its use in Windows+Vulkan, so I'll do that next.

I'm trying to move the logic to a common place that can be used by both Direct3D and Vulkan. I'm finding a little block however. Currently I see no way to distinguish Vulkan+Windows from Vulkan+Linux or Vulkan+MacOS. Direct3D is obviously only Windows, but I do not want to ship the internal Win32 interop logic for those other platforms.

I want to use conditional compilation, but only define that I can use is STRIDE_PLATFORM_DESKTOP (which is both for Windows and other desktop platforms) and STRIDE_GRAPHICS_API_X (which does not convey platform, only graphics API).
The SDK defines a StridePlatform which I have verified is Windows when compiling Stride.Graphics. It is however never surfaced in DefineConstants. Also, .NET SDK can also define WINDOWS, LINUX, etc., but as Stride.Graphics is built with TargetFramework=net10.0 (no -windows or -linux suffixes), those are also unavailable here.

So, what should I do? Options are leaving this as DX-only for now (the only one I can guarantee it is Windows), or modify the SDK to define something like STRIDE_PLATFORM_WINDOWS that I can check in an #if.

@Kryptos-FR You modernized the SDK recently. Do you think it is feasible and desirable to add something like STRIDE_PLATFORM_WINDOWS?

@Ethereal77
Copy link
Copy Markdown
Contributor Author

I don't have fully grasped the new SDK build system, so excuse if this is not correct.

I have modified the following lines in Stride.Platforms.targets:

  <!-- ================================================================ -->
  <!-- Platform Defines - Desktop Frameworks -->
  <!-- ================================================================ -->
  <PropertyGroup Condition="'$(TargetFramework)' == '$(StrideFramework)' Or '$(TargetFramework)' == '$(StrideFrameworkWindows)'">
    <StridePlatformDefines>STRIDE_PLATFORM_DESKTOP</StridePlatformDefines>

    <StridePlatformDefines Condition="'$(StridePlatform)' == 'Windows'">$(StridePlatformDefines); STRIDE_PLATFORM_WINDOWS</StridePlatformDefines>
    <StridePlatformDefines Condition="'$(StridePlatform)' == 'Linux'">$(StridePlatformDefines); STRIDE_PLATFORM_LINUX</StridePlatformDefines>
    <StridePlatformDefines Condition="'$(StridePlatform)' == 'macOS'">$(StridePlatformDefines); STRIDE_PLATFORM_MACOS</StridePlatformDefines>
  </PropertyGroup>

It seems to work. When checking the MSBuild log, it appears the correct constants are defined in addition to STRIDE_PLATFORM_DESKTOP. I don't know however if this may have other implications, and I can't test on Linux or macOS.

@xen2 xen2 force-pushed the master branch 2 times, most recently from ab329f3 to 482bd28 Compare April 16, 2026 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant