New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fullscreen on Windows on HDPI screen not working if upscaling is enabled #676

Open
badlogic opened this Issue Dec 29, 2015 · 8 comments

Comments

Projects
None yet
5 participants
@badlogic

badlogic commented Dec 29, 2015

By default, Windows 10 enables upscaling for executables that don't set the respective properties in the executables manifest.

On a HDPI monitor (e.g. 4k) and with the Windows wide HDPI scaling set to > 100%, GLFW fails to properly create a fullscreen window at below native-resolution if upscaling is enabled. Instead of the entire screen being covered, only parts of it are allocated to the fullscreen window.

In the same scenario (4k monitor, below native resolution fullscreen window), but with the global HDPI scale set to 100%, GLFW manages to create the fullscreen window properly such that it covers the entire screen. However, the window never gains focus, neither automatically not by switching focus from and back to the window.

If the fullscreen window uses native resolution, GLFW succeeds in creating it and having the input focus work correctly for both 100% scale and scale != 100%.

If upscaling is explicitely disabled, either via a manifest entry or by manually setting it in the properties of the executable in Windows Explorer, all scenarios (scale != 100%, resolution != native, resultion == native) work as intended.

@slime73

This comment has been minimized.

Show comment
Hide comment
@slime73

slime73 Jan 5, 2016

On a HDPI monitor (e.g. 4k) and with the Windows wide HDPI scaling set to > 100%, GLFW fails to properly create a fullscreen window at below native-resolution if upscaling is enabled. Instead of the entire screen being covered, only parts of it are allocated to the fullscreen window.

That's a problem with Windows itself I think.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#partial_rendering_of_a_full_screen_application

Partial Rendering of a Full-screen Application

DPI virtualization sometimes causes partial rendering of a full screen application. In most cases, this side effect of DPI virtualization occurs in full-screen gaming applications because they commonly do programmatic screen resolution mode changes. This issue affects only Windows Vista or later applications that do not declare themselves as DPI–aware. Because virtualized applications get scaled system metrics, an application that changes the display mode based on these metrics may change the display to an incorrect mode while virtualized. Since full screen applications like games are natively resolution-independent, in most cases this means they are also natively DPI independent. The recommended solution for this class of applications is to declare themselves as per monitor-DPI aware. Note that some applications may have windowed-mode installers and uninstallers, so it is important to do an application test pass according to the DPI testing guidelines to ensure that the application behaves properly at high DPI.

slime73 commented Jan 5, 2016

On a HDPI monitor (e.g. 4k) and with the Windows wide HDPI scaling set to > 100%, GLFW fails to properly create a fullscreen window at below native-resolution if upscaling is enabled. Instead of the entire screen being covered, only parts of it are allocated to the fullscreen window.

That's a problem with Windows itself I think.

https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#partial_rendering_of_a_full_screen_application

Partial Rendering of a Full-screen Application

DPI virtualization sometimes causes partial rendering of a full screen application. In most cases, this side effect of DPI virtualization occurs in full-screen gaming applications because they commonly do programmatic screen resolution mode changes. This issue affects only Windows Vista or later applications that do not declare themselves as DPI–aware. Because virtualized applications get scaled system metrics, an application that changes the display mode based on these metrics may change the display to an incorrect mode while virtualized. Since full screen applications like games are natively resolution-independent, in most cases this means they are also natively DPI independent. The recommended solution for this class of applications is to declare themselves as per monitor-DPI aware. Note that some applications may have windowed-mode installers and uninstallers, so it is important to do an application test pass according to the DPI testing guidelines to ensure that the application behaves properly at high DPI.

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Feb 28, 2016

Member

I unfortunately can't work on this one because I don't have a spare machine I can infest with Windows 10.

Member

elmindreda commented Feb 28, 2016

I unfortunately can't work on this one because I don't have a spare machine I can infest with Windows 10.

@badlogic

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Feb 28, 2016

I'd happily pay for a cheap(ish) machine if this helps. Not sure what your
policies are regarding such sponsorship.
On Feb 28, 2016 8:14 PM, "Camilla Berglund" notifications@github.com
wrote:

I unfortunately can't work on this one because I don't have a spare
machine I can infest with Windows 10.


Reply to this email directly or view it on GitHub
#676 (comment).

badlogic commented Feb 28, 2016

I'd happily pay for a cheap(ish) machine if this helps. Not sure what your
policies are regarding such sponsorship.
On Feb 28, 2016 8:14 PM, "Camilla Berglund" notifications@github.com
wrote:

I unfortunately can't work on this one because I don't have a spare
machine I can infest with Windows 10.


Reply to this email directly or view it on GitHub
#676 (comment).

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Feb 29, 2016

Member

@badlogic Um, wow, thank you! That would be extremely helpful. I don't expect this to be the last bug specific to 10. If you think it'd be worth it to you then I accept.

There's no policy for GLFW. My own, such as it is, is to accept donations when it'll help me work on the project.

Member

elmindreda commented Feb 29, 2016

@badlogic Um, wow, thank you! That would be extremely helpful. I don't expect this to be the last bug specific to 10. If you think it'd be worth it to you then I accept.

There's no policy for GLFW. My own, such as it is, is to accept donations when it'll help me work on the project.

@badlogic

This comment has been minimized.

Show comment
Hide comment
@badlogic

badlogic Feb 29, 2016

Please contact me at mario at badlogicgames dot com and we can figure out
the details!
On Feb 29, 2016 5:46 PM, "Camilla Berglund" notifications@github.com
wrote:

@badlogic https://github.com/badlogic Um, wow, thank you! That would be
extremely helpful. I don't expect this to be the last bug specific to 10.
If you think it'd be worth it to you then I accept.

There's no policy for GLFW. My own, such as it is, is to accept donations
when it'll help me work on the project.


Reply to this email directly or view it on GitHub
#676 (comment).

badlogic commented Feb 29, 2016

Please contact me at mario at badlogicgames dot com and we can figure out
the details!
On Feb 29, 2016 5:46 PM, "Camilla Berglund" notifications@github.com
wrote:

@badlogic https://github.com/badlogic Um, wow, thank you! That would be
extremely helpful. I don't expect this to be the last bug specific to 10.
If you think it'd be worth it to you then I accept.

There's no policy for GLFW. My own, such as it is, is to accept donations
when it'll help me work on the project.


Reply to this email directly or view it on GitHub
#676 (comment).

@elmindreda

This comment has been minimized.

Show comment
Hide comment
@elmindreda

elmindreda Mar 2, 2016

Member

Windows 10 machine: achieved

Member

elmindreda commented Mar 2, 2016

Windows 10 machine: achieved

@elmindreda elmindreda self-assigned this Mar 2, 2016

@miroandel

This comment has been minimized.

Show comment
Hide comment
@miroandel

miroandel Mar 8, 2016

In visual studio 2015 this setting does the trick and solves the fullscreen issue.
skarmklipp 2016-03-08 08 24 54

However it would be nice setting this using cmake. Need to investigate this a bit. However, it would be good to add a feature to GLFW to be able to retrieve the per monitor scaling variable to be able to render fonts and other objects correctly. When not running fullscreen the scaling also affects the positioning of windows.

miroandel commented Mar 8, 2016

In visual studio 2015 this setting does the trick and solves the fullscreen issue.
skarmklipp 2016-03-08 08 24 54

However it would be nice setting this using cmake. Need to investigate this a bit. However, it would be good to add a feature to GLFW to be able to retrieve the per monitor scaling variable to be able to render fonts and other objects correctly. When not running fullscreen the scaling also affects the positioning of windows.

@elmindreda elmindreda added the High DPI label Mar 13, 2016

@elmindreda elmindreda added this to the 3.3 milestone May 18, 2016

@fralken

This comment has been minimized.

Show comment
Hide comment
@fralken

fralken Jun 8, 2016

Hello, now that version 3.2 is out I can see that the per-monitor-DPI-awareness is managed, that is, even if the manifest property is not set, it is set by GLFW itself at runtime and hence the WM_DPICHANGED event is triggered when moving a window across two monitors with different DPI. That's ok.

Anyway, it still doesn't manage a monitor with DPI != 100%.
For example, my primary monitor has DPI=240 (that is 250% since the default is 96), while btw my secondary monitor has DPI=96.

A window created on the primary monitor is still created in actual pixels and not in screen coordinates, as stated in the documentation.
Any plan on trying addressing this issue? :)
Thanks

fralken commented Jun 8, 2016

Hello, now that version 3.2 is out I can see that the per-monitor-DPI-awareness is managed, that is, even if the manifest property is not set, it is set by GLFW itself at runtime and hence the WM_DPICHANGED event is triggered when moving a window across two monitors with different DPI. That's ok.

Anyway, it still doesn't manage a monitor with DPI != 100%.
For example, my primary monitor has DPI=240 (that is 250% since the default is 96), while btw my secondary monitor has DPI=96.

A window created on the primary monitor is still created in actual pixels and not in screen coordinates, as stated in the documentation.
Any plan on trying addressing this issue? :)
Thanks

@elmindreda elmindreda added the blocking label Dec 11, 2016

@elmindreda elmindreda removed the blocking label Mar 27, 2017

@xGnoSiSx xGnoSiSx referenced this issue Oct 9, 2017

Open

LWJGL 3 backend V-Sync problem on desktop #4274

1 of 7 tasks complete

@elmindreda elmindreda referenced this issue Oct 17, 2017

Open

3.3 release coordination #1098

5 of 9 tasks complete

elmindreda added a commit that referenced this issue Aug 22, 2018

Add GLFW_WIN32_DPI_RESIZE
Related to #676.
Related to #1115.

elmindreda added a commit that referenced this issue Aug 22, 2018

Add GLFW_X11_DPI_RESIZE
Related to #676.
Related to #1115.

elmindreda added a commit that referenced this issue Sep 3, 2018

Add GLFW_SCALE_TO_MONITOR
This adds the GLFW_SCALE_TO_MONITOR window hint for automatically
resizing the content area of a window to the requested size times the
monitor content scale each time it is placed on a new monitor.  This
only applies to windowed mode windows and includes the initial placement
at window creation.

This hint only has an effect on platforms where screen coordinates and
pixels always map 1:1 such as Windows and X11.  Platforms like macOS
instead change the resolution of the framebuffer independently of the
window size.

Related to #676.
Related to #1115.

elmindreda added a commit that referenced this issue Sep 3, 2018

Add GLFW_SCALE_TO_MONITOR
This adds the GLFW_SCALE_TO_MONITOR window hint for automatically
resizing the content area of a window to the requested size times the
monitor content scale each time it is placed on a new monitor.  This
only applies to windowed mode windows and includes the initial placement
at window creation.

This hint only has an effect on platforms where screen coordinates and
pixels always map 1:1 such as Windows and X11.  Platforms like macOS
instead change the resolution of the framebuffer independently of the
window size.

Related to #676.
Related to #1115.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment