Unification of HDPI scaling across platforms

[badlogic]

On Mac OS X, GLFW reports screen sizes and framebuffer sizes properly if upscaling is enabled in the OS. E.g. on a "retina" display at 2x upscaling, creating a window at 900x600 screen size will result in a 1800x1200 frame buffer size.

For the same scenario on Windows, with HDPI scaling set to 200%, the window size is actually interpreted as the framebuffer size, not the screen size. This results in a window of framebuffer size 900x600 pixels instead of 1800x1200 pixels. The window's screen size is then actually smaller as what was specified during window creation (450x300 at 200% upscaling). However, GLFW reports the framebuffer size as the screen size (900x600), which makes detection and handling of HDPI upscaling impossible on Windows.

I have not tested this on Linux. My assumption would be that it probably works like on Windows (screen size == framebuffer size irrespective of upscaling settings).

It'd be great if this worked the same on all operating systems, preferably the way it works on Mac OS X, with the screen size and framebuffer size being reported according to the upscaling setting of the OS.

If fixing this transparently is not possible, it'd be great if GLFW could expose the upscaling factor so users can perform platform specific work-arounds.

[j6lim]

+1

[claudiofantacci]

Hello, I was looking for updates on this issue and I just read this commit.

Am I correct saying that GLFW_HIDPI_RESIZEwindow hint will be released in the next GLFW release (3.3)?

[felselva]

I have not tested this on Linux. My assumption would be that it probably works like on Windows (screen size == framebuffer size irrespective of upscaling settings).

I don't believe this feature is needed on Linux.

On Linux, HDPI is defined by the desktop enviroment, and there are many desktop enviroment. Each DE will report the HDPI scale in a different way (may be a configuration file, using a library or a configuration system like dconf). Best way is to check how the DEs that you want to support HDPI report these and implement a solution for them.

[claudiofantacci]

By my understanding of this documentation

GLFW_HIDPI_RESIZE specifies whether the windowed mode window will resize
either its framebuffer or both itself and the framebuffer when it is moved to
a monitor with a significantly different DPI.

On Windows 8.1 and later, this will cause both the window and its
framebuffer to resize when it is moved to a monitor with a different DPI.  The
new size makes the window appear approximately as large (measured in mm on the
monitor) as on the previous monitor.  If disabled the window will not be resized
when moved between monitors.

On OS X 10.7 and later, if enabled this hint will cause the
framebuffer of the window to resize to an integer multiple of the window size,
letting OpenGL render at the full resolution of Retina monitors while the rest
of the UI appears not to resize.  If disabled rendering will not use Retina
resolution in either full screen or windowed modes.

and by the X11 behaviour described in this comment

On X11 you only get a DPI value and have to do the rest yourself.
Pixels and screen coordinates always map 1:1 (modulo compositors) and the
window system has no concept of a high-DPI mode.

the new feature should only affect Windows and macOS OSs.

[edwinRNDR]

I am (still) seeing the same issues as originally reported by @badlogic on master (34d20b0). On Windows 10 the window size is equal to framebuffer size on systems that report a content scaling of 2.0. Is this the intended behaviour? If so what tools are there to make sure I am creating the window at the right size?

[elmindreda]

That is the intended behavior. The window size and framebuffer size will always match on Windows and X11. On those platforms, the window (and framebuffer) is resized according to the monitor's scale. If you have GLFW_SCALE_TO_MONITOR enabled and tell GLFW to create a 640x480 window on a monitor with scaling factor 2.0, the initial size of both the window and framebuffer will be 1280x960.

Edit: If you then move it to a monitor with scaling factor 1.5, it will resize (window and framebuffer) to 960x720.

[mokafolio]

@elmindreda ugh, i deleted the comment because I realized I was accidentally still linking against the glfw that I installed with apt and your response was not showing at the time.

So what is the proper way to deal with the differences across platforms then? i.e. On windows and ubuntu I get the same value for window size and framebuffer but what I really want to get from window size is the original size I put in because i.e. I use that to setup certain projections. To handle this case properly, will I need to check platform and the scalefactor and do the right thing accordingly?

Wouldn't it be better if glfw decides on one way of how to go about this and consistently does it across platforms? I am propably missing something, just thinking out loud.

Thanks!

[mokafolio]

Just to illustrate why I agree with @badlogic that the way osx does it is better (i.e. separate between window size and framebuffer size). Let's say you have some code that works in a sequence like this:

1. create window at 800x600
2. create an ortho projection based on glfwGetWindowSize
3. draw stuff hardcoded based on that window size (i.e. at the center, 400x300)

While in a lot of high end code, you'll hopefully not encounter this, it is very common for basic examples (where glfw is used very often).

On osx, the above still works perfectly fine. On linux (and windows) this wont work anymore without doing a lot of extra lifting to determine if we are on a hidpi display or not etc.

Either way, I think it would be lovely if glfw would pick one way (i.e. either the windows/linux or osx) and stick with it.