DPI scaling is incorrectly determined on X11 Linux

[whitequark]

This happens because it uses GLFW and GLFW currently retrieves content scale via "folklore heuristics" (their words) which do not really work: https://github.com/glfw/glfw/blob/b35641f4a3c62aa86a0b3c983d163bc0fe36026d/src/x11_init.c#L990-L1023

On X11 there's no unified way to do this. The best you could do in a fully arch-independent manner is to query RandR display DPI, but that's kind of a pain to do. An alternative is to look at GDK/Qt environment variables.

[whitequark]

I've submitted #725 as an example of how to make DPI scaling determination work pretty okay on X11 Linux, but it still needs to be tested on Wayland Linux, Windows, and macOS. Personally I'm willing to do that once the ffts dependency is no longer something I have to build.

[nemanjan00]

Scaling also seems to be completely broken on Wayland. (Sway)

I am not sure if cause is also GLFW

I have a hack (temporary "solution") that might help some people.

It does seem to at least fix cursor alignment to buttons and to render with reasonable resolution

gamescope -W 1440 -H 900 -r 60 -- ngscopeclient

[MonarchActual]

I have the same issue on wayland (sway).
gamescope also does not work because of an issue with my intel integrated GPU.
As a workaround I use Xwayland using XDG_SESSION_TYPE=x11.
This works fine for me but I am using the default scale of 1 / DPI of 96.

[azonenberg]

I'm gonna bump this to 0.2 for now. We've fixed most of the DPI issues, if there's a few remaining ones blocking this ticket I don't want to hold up the release for them.

0.1.1 is supposed to be a quick maintenance release to fix all the stuff people found post 0.1 so I don't want to delay it much further.

[nemanjan00]

Last time I tested it, it seemed fine. And I believe my setup is exotic enough that if it works for me reasonably well, it probably works ok for people with more "normal" setup

[Elemecca]

X11

I don't disagree that finding the correct DPI on X11 is a bit fraught. GLFW is using the Xft.dpi X resource value, which is arguably incorrect, but in my experience it does work reliably on all of the major desktop environments, and setting that value in .Xresources is one of the steps I'm used to having to do to get DPI scaling working properly in less vertically integrated setups with AwesomeWM or XMonad.

Independent of determining what DPI to use, we had many bugs in applying DPI scaling to the UI that caused a variety of visual artifacts. As of #922 I believe all of those have been fixed, and the application renders correctly for me with XWayland under KDE Plasma / KWin (which does set Xft.dpi correctly). I haven't tried in a native X11 session.

@whitequark does DPI scaling under X11 work correctly for you on the current master, or are you still seeing issues?

Wayland

The Wayland / Sway issues in the comments are somewhat off topic to the original description, which is about the above X11 issues. They appear to be the same issue that was eventually fixed in 0c04bcb pursuant to #824.

I was able to replicate the provided screenshots in 812625e (which would have been the tip of master at the time of nemanjan00's comment) in a KDE Plasma Wayland session. The current master version (7142842) behaves correctly in the same environment.