DPI Awareness Issue on Windows

[AnotherCommander]

Distributed version 0.002 is currently not DPI aware and will generate a wrong size window on startup, depending on the scaling set in Windows.

This is easily fixable by adding this manifest in a resource file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
        <application> 
            <!-- Windows 10 --> 
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
            <!-- Windows 8.1 -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <!-- Windows Vista -->
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
            <!-- Windows 7 -->
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
            <!-- Windows 8 -->
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
        </application> 
    </compatibility>
    <application xmlns="urn:schemas-microsoft-com:asm.v3">
        <windowsSettings>
            <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings%22%3Etrue/PM</dpiAware>
            <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings%22%3EPerMonitorV2, PerMonitor</dpiAwareness>
        </windowsSettings>
    </application>
</assembly>

Declare in resource file as
1 24 "lt64.exe.manifest"
where lt64.exe.manifest is the file containing the earlier posted manifest contents.

Alternatively, this is fixable by right clicking on the lt64.exe -> Properties -> Compatibility tab -> Change high DPI settings -> Check High DPI scaling override, then OK everything. Of course the second method requires user interaction, while the first is fix-and-forget.

[dgavedissian]

I think fixing this is a matter of passing SDL_WINDOW_ALLOW_HIGHDPI to SDL_CreateWindow: https://wiki.libsdl.org/SDL2/SDL_WindowFlags, which would work on macOS and Linux as well.

[philip-uk]

@AnotherCommander I tried changing my Windows scaling and it change the size of everything. I am not quite sure what is expected to happen here? The default window is 1600x900 and obviously fits easily on my 2560x1440 screen. If I set to 125% (or whatever), I end up with the game window nearly filling my screen. I don't know if that is right or wrong though - everything else goes big too of course.

[AnotherCommander]

@philip-uk The correct and expected behavior is that the window size requested by the application is respected regardless of the DPI scaling. So, what you are seeing is the bug in action - the window should not be filling a larger area when the scaling is increased. To see what it should look like, you can follow the alternative fix method described in my original post on this issue. This should be the behavior by default and this is what both @dgavedissian 's and my proposed fixes do. The former is probably the simplest and quickest, while the latter is the one recommended by Microsoft. ( as seen in https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process ).

[philip-uk]

Addressed by #43

[philip-uk]

@AnotherCommander Please confirm that the DPI is now working for you.

[AnotherCommander]

I will only be able to test in a couple of days - sorry for not being able to provide feedback earlier, will let you know asap how it goes.

…

On Sat, Mar 25, 2023, 11:47 philuk ***@***.***> wrote: @AnotherCommander <https://github.com/AnotherCommander> Please confirm that the DPI is now working for you. — Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYHJVZLR62766RZKZ2TJDW525KJANCNFSM6AAAAAAU7VNQEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AnotherCommander]

Confirming that it works fine now. This issue can be closed.

[dgavedissian]

I realised that adding SDL_WINDOW_ALLOW_HIGHDPI broke rendering pretty badly on macOS:

I believe the problem is that SDL_WINDOW_ALLOW_HIGHDPI tells SDL2 to create a window that is 1600x900 "points", which is actually a render surface of 3200x1800 pixels, however the libphx engine assumes the OpenGL viewport is 1600x900 pixels, hence why it only gets rendered in the corner.

This flag also doesn't work at all on Windows, which is why the manifest was required there, see:

• New High DPI Support API is needed libsdl-org/SDL#2119

I think on Windows, what's happening is that with the manifest, Windows will no longer do anything except send WM_DPICHANGE events, and I think we are currently ignoring them. That means on HiDPI machines, the window will be exactly 1600x900 and Windows will not scale the window up by 125%/150%/200% (and make the image blurry). However, the engine currently makes no attempt to actually size the window correctly and make sure the GL viewport is correct.

It seems that more official support was merged in libsdl-org/SDL#5778 which has a new SDL_WINDOWS_DPI_SCALING window flag.

I think I'm going to re-open this issue, remove the SDL_WINDOW_ALLOW_HIGHDPI flag for the time being, to revert macOS to the state it was in before. Then, we can think about how to make sure libphx is aware that the size of the window and the size of the render viewport isn't necessarily the same:

i.e., as long as it uses SDL_GL_GetDrawableSize/SDL_GetRendererOutputSize() and doesn't assume SDL_GetWindowSize() is the drawable size in pixels).