XIVLauncher.Core icon indicating copy to clipboard operation
XIVLauncher.Core copied to clipboard

Fix HiDPI scaling on X11 and XWayland (#88)

Open Maia-Everett opened this issue 2 years ago • 10 comments

Ensure that when running with the SDL X11 driver under Wayland, the window is correctly scaled (and is crisp rather than blurry).

See #88.

Maia-Everett avatar Apr 21 '24 20:04 Maia-Everett

I should warn that it does mess up the layout somewhat.

Here's how the unscaled window looks on my 4K monitor:

image

Here's the window with the scaling patch. The layout is messed up a bit, but the text is readable and everything is crisp.

image

And here's what happens if I multiply FontGlobalScale but leave ImGuiBindings intact. The layout is messed up in a different way, and the fonts are blurry (while with the patch as implemented in the PR, the fonts are sharp).

image

I assume you'll know what to do, though. For me, it's not a deal breaker.

Maia-Everett avatar Apr 21 '24 21:04 Maia-Everett

Added a PR on Maia-Everett:wayland-hidpi for changes to allow everything to scale. It was a bit too much to add as a series of comments, since it touches 22 files in all.

I am encountering one oddity, though. When I check the scaling factor being applied, I'm getting 1.5875, despite having scaling set at 1.5 in kde. Not sure where it's getting that number.

rankynbass avatar Apr 22 '24 03:04 rankynbass

I am encountering one oddity, though. When I check the scaling factor being applied, I'm getting 1.5875, despite having scaling set at 1.5 in kde. Not sure where it's getting that number.

I've added verbose logging for that, and it seems SDL calculates DPI based on the physical dimensions of the screen. For my primary monitor, it reports 162.56x161.3647, whereas for scaling purposes I'd want 192 DPI reported (since my desktop uses 200% scaling with 4K resolution 3840x2160).

Querying the desktop environment itself will return the value we actually want. And how do you obtain the scaling value the DE uses? Lol, lmao. By using a variety of DE-specific methods of various levels of hackishness, apparently.

I'll change it.

Maia-Everett avatar Apr 22 '24 09:04 Maia-Everett

Just curious, is there nothing in Veldrid that can be used for that?

marzent avatar Apr 22 '24 09:04 marzent

Just curious, is there nothing in Veldrid that can be used for that?

Unfortunately, no. Grepping scale across the Veldrid source returns nothing relevant.

For KDE specifically, my plan is to query kscreen-doctor -j and then parse the JSON output for the scaling factor of the monitor with x: 0, y: 0 (it always exists). It returns the correct fractional scaling value.

For GNOME and other DEs, I don't know a reliable way to query fractional scaling, so we can fall back to gsettings get org.gnome.desktop.interface scaling-factor, then xrdb -query, and finally SDL (which returns an incorrect but not-too-badly-incorrect value), in that order.

Maia-Everett avatar Apr 22 '24 10:04 Maia-Everett

Pushed new commits:

  • Scaling is now obtained from the desktop environment if possible, falling back to SDL.
  • The news banner is also scaled.

Thanks for your scaling support, @rankynbass! The PR is now feature-complete.

Here's how it looks at 200% scaling in KDE:

image

and at 150%:

image

This fix only applies to XWayland. Native Wayland rendering when running with SDL_VIDEODRIVER=wayland is still blurry, but that's a separate issue.

Maia-Everett avatar Apr 22 '24 11:04 Maia-Everett

~It turns out that with native Wayland, SDL natively supports HiDPI scaling and resizes the window drawable accordingly while still accepting and reporting an unscaled window size — but only if you pass it SDL_WindowFlags.AllowHighDpi, which Veldrid doesn't set (I'll file an issue for that).~

~So all that's needed to do is to obtain that scale factor from SDL and pass it to OpenGL and ImGUI so they correctly scale the viewport and drawing respectively, which I've now done. So as of the latest commit, HiDPI scaling correctly works with both XWayland and native Wayland with no blurriness.~

Edit: I've reverted the native Wayland commit for now because it breaks mouse input. It's still in commit history if someone wants to work on top of that. For now, you can merge the XWayland changes, and we can look at native Wayland scaling later.

Maia-Everett avatar Apr 22 '24 12:04 Maia-Everett

I've fixed the native Wayland scaling fixes and pushed them to a separate branch:

https://github.com/Maia-Everett/XIVLauncher.Core/compare/wayland-hidpi...Maia-Everett:XIVLauncher.Core:wayland-native-hidpi

I can make a separate PR after this is merged. I'll keep this PR focused on XWayland.

Maia-Everett avatar Apr 22 '24 17:04 Maia-Everett

I checked under KDE Plasma 6.1 with X11, and the scaling issue is present there too, so it's not just XWayland.

Maia-Everett avatar Oct 02 '24 10:10 Maia-Everett

The main problem with this patch is that it doesn't have a fallback if the scale is for some reason set to 0. This can happen sometimes in flatpak; the gnome scaling may sometimes be read as 0, and then no window is shown.

So in the DesktopHelpers.cs file, the individual GetXXXScaleFactor() functions should be checked to make sure that if they return a float, it is at least 1, or at the very least it should never be 0.

rankynbass avatar Feb 24 '25 03:02 rankynbass