goatcorp / XIVLauncher.Core

Cross-platform version of XIVLauncher, optimized for Steam Deck
GNU General Public License v3.0
84 stars 35 forks source link

Fix HiDPI scaling on XWayland (#88) #152

Open Maia-Everett opened 3 weeks ago

Maia-Everett commented 3 weeks ago

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 commented 3 weeks ago

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.

rankynbass commented 3 weeks ago

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.

Maia-Everett commented 3 weeks ago

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.

marzent commented 3 weeks ago

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

Maia-Everett commented 3 weeks ago

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 commented 3 weeks ago

Pushed new commits:

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 commented 3 weeks ago

~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 commented 3 weeks ago

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.