feat: Surface Monitor DPI Scaling in GraphicsOutput and Improve DPI Awareness

[VaclavElias]

Is your feature request related to a problem? Please describe.
Font rendering becomes blurry or incorrectly scaled on high-DPI monitors when display scaling is above 100%. The issue is not with the font but with how DPI scaling is handled. As a workaround, manual hacks or Silk.NET APIs (such as GetMonitorContentScale) can be used, but this is not ideal.

Describe the solution you'd like
Expose monitor DPI scaling information (e.g., using GetMonitorContentScale from Silk.NET, SDL API, Windows DXGI, or platform equivalents) probably from GraphicsOutput. This would allow consumers (toolkits, samples, games) to adjust font and UI rendering appropriately for different DPI settings. Ideally, the engine could also detect when the window moves between screens and update scaling automatically. DPI awareness should be opt-in at first, surfacing the information and allowing users to handle it as needed, with further engine support potentially added later.

Describe alternatives you've considered

• Manual hacks to resize window and font for sharpness
• Using Silk.NET or platform APIs directly in user code
• Relying on game/system DPI settings without explicit detection

Additional context

• Silk.NET exposes monitor scaling through GetMonitorContentScale
• DXGI (Windows), SDL (cross-platform), and other APIs provide similar data
• Box2D.NET samples correctly handle font scaling across different DPI settings and screens
• Implementation should be cross-platform, with Windows, Linux, and Mac support as feasible
• See discussion: https://stackoverflow.com/a/54628671/1745070
• Example workaround in Stride Community Toolkit
• Fonts should scale as the monitor DPI or scaling factor changes, similar to how Box2D.NET does it
• Consider how other engines handle DPI and allow opt-in behavior
• The developer should decide and control how the game behaves when DPI is changed. Maybe all gets resized, maybe just game UI, maybe just some entities?

Here are some questions that can aid in the description of the feature request:

• Use cases include rendering sharp fonts, UI, and content across multiple monitors and DPI settings
• Expected options: ability to query DPI scaling, opt-in DPI-aware mode, possibly engine-managed scaling in the future
• Pseudocode: GraphicsOutput.GetMonitorContentScale() -> float uiScale
• Editor impact: DPI scaling info accessible, but opt-in rendering adjustments
• May require updates to GraphicsOutput, platform abstraction, and documentation
• Example project [WIP]: Stride Community Toolkit ImGui sample

Screen: Current State on 4K with 175% Scale. Click on the image to see it better.

Image 1

• blurred font
• blurred shapes

Image 2 - Adding a helper WindowsDpiManager.EnablePerMonitorV2(); which enables DPI awareness

• sharp font - here is where we would need DPI and the game would need to resize the font (make it bigger) based on the developer choice (maybe not)
• sharp shapes - here is where we would need DPI and make some adjustments maybe in the thickness of the outlines, again the developer has to decide?

[VaclavElias]

I have added some images to the issue description.

[VaclavElias]

@Ethereal77 I have some additional info. The DPI awareness is currently set through app.manifest which is automatically created in the Windows project when we use any Stride templates.

app.manifest

<?xml version="1.0" encoding="utf-8"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
             If you want to change the Windows User Account Control level replace the 
             requestedExecutionLevel node with one of the following.

        <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

            Specifying requestedExecutionLevel element will disable file and registry virtualization. 
            Remove this element if your application requires this virtualization for backwards
            compatibility.
        -->
        <requestedExecutionLevel level="asInvoker" uiAccess="false" />
      </requestedPrivileges>
    </security>
  </trustInfo>

  <!-- Indicates that the application is DPI-aware and will not be automatically scaled by Windows at higher
       DPIs. Windows Presentation Foundation (WPF) applications are automatically DPI-aware and do not need 
       to opt in. Windows Forms applications targeting .NET Framework 4.6 that opt into this setting, should 
       also set the 'EnableWindowsFormsHighDpiAutoResizing' setting to 'true' in their app.config. -->

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <!-- The combination of below two tags have the following effect : 
           1) Per-Monitor for >= RS1 (Windows 10 Anniversary Update)
           2) System < RS1
      -->
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitor</dpiAwareness>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
    </windowsSettings>
  </application>

</assembly>

And the MyProject.Windows.csproj has this: <ApplicationManifest>app.manifest</ApplicationManifest>

[Eideren]

An alternative workaround that may be crossplatform would be to add Silk.NET.GLFW nuget and call

var api = Silk.NET.GLFW.Glfw.GetApi();
api.Init();
api.Terminate();

Before starting your game. GLFW seem to notify Windows that it should disable DPI scaling for the application.

You can still query scaling through api.GetMonitorContentScale(myMonitor, out var x, out var y); if you want

[Ethereal77]

Hmm... I can investigate what is doing GLFW there under the hood and try to replicate it using Win32.

I remember having investigated how to surface per-screen DPI config as fields in GraphicsOutput. When I have time I can look into it again.

@Eideren Note that we currently set high-DPI with WindowFlags.AllowHighdpi when initializing SDL. If the intent is to disable high-DPI for certain use cases, maybe we should make it configurable. Is that what you were referring to?

[Eideren]

@Ethereal77 We have to disable high-dpi for the application in our case as we don't have any way to query the right backbuffer resolution, high dpi forces all calls that I have tested to return the resolution of the monitor reduced by that scaling. SDL 3/Silk.Net 3 would give us a way to query display scaling if I remember right.
I have not tried to remove that sdl flag to see if that resolved the issue for sdl.

[Eideren]

To add more context, here's what I looked into at the time:
Winforms has a DeviceDPI field for the window, which reports a dummy dpi by default. Not sure what we need to do to make that work.
SDL does have SDL_GetWindowSizeInPixels and SDL_GetWindowSize, which could provide different values. But that's not the case when I tested this out, maybe removing the flag helps there, no idea. SDL3 has a SDL_GetDisplayContentScale.
Silk2 does surface it, but only through their own windowing system afaict.

[Ethereal77]

I'm starting to implement a simple way to get the DPI of the screen in #3132

Do you have any requirements or ideas for this?

[VaclavElias]

Thanks for looking into this. I don't personally have anything else to add, but I hope others can share some ideas.