Thread with 14 posts
jump to expanded post
oh shit WINE 10 fixed the big problems with high-DPI, it did not work anywhere near this well when we were trying this out in WINE 9, a year and a half ago
look at how it handles 144dpi (default is 96dpi):
- winecfg and explorer are dpi-aware
- mspaint gets upscaled
perfect!
@hikari omg it would be fricking hilarious if it turns out x11/electron apps do not upscale correctly in gnome!wayland at 1.5x DPI but wine/win32 apps do
@mcc we're currently using GNOME Wayback as our desktop on this Debian install and it doesn't even offer fractional scaling, perhaps because it's using X, so it's kind of amazing to see that WINE does and that it actually works properly now
(unfortunately we have also discovered that when running WINE directly against Wayland rather than with Xwayland it somehow doesn't work correctly: it looks like the Wayland server might be scaling the windows down, nullifying the increased resolution?! but I suspect that is a simple bug that can easily be fixed)
@hikari Here is my current understanding
- Wayland has two types of DPI scaling: One which works on integers and is older, one which works fractionally and is less well supported.
- X I'm confused by but I *believe* it has no DPI, just a general ability to scale things up. Pre Wayland this was used to simulate DPI changes and worked.
- Mutter (GNOME) is probably the worst of the Wayland servers. KDE supports far more extensions.
- GNOME specifically handles fractional DPI badly wrt X.
(@not 39c3)
,
@leo@60228.dev
@mcc @hikari my understanding is that on wayland the texture-space and (scaled) screen-space sizes for a window don't have to match and it's just scaled like any other texture, and the problem is that gnome spent many years dragging their feet on exposing a way for mutter to expose a preferred scaling factor that wasn't an integer
(@not 39c3)
,
@leo@60228.dev
(@not 39c3)
,
@leo@60228.dev
@leo @mcc @hikari no. absolutely not, what are you talking about?! literally mclasen himself uses 125% scaling since 2024. lots of work went into fractional scaling, like the rounding consistency for text in the linked post. mutter is even smart about which factors to use to not cause blur these days.
@valpackett what I am talking about is that I have been using gnome on a Lenovo 1.5x laptop for about two years now (on Ubuntu 23.something and then Debian Trixie) and have had a bad experience. X11 apps, which means almost all Electron apps and still includes Bitwarden, are blurry.
I will check and see which setting it was that failed to work
(@not 39c3)
,
@leo@60228.dev
- When GNOME wants to fractional-DPI an XWayland window, what it does is it rounds down to the nearest integer DPI, X-scales the X window to that integer, then physically scales up by bilinear scaling the window to the fractional resolution to display it in wayland. Alternately there is a setting to make it do the opposite (X-scale up to integer, bilinear-scale down to fractional). it's awful. KDE just "does it correctly" (tells the app to X-scale then draws it)
- Based on this, it wouldn't surprise me if whatever in GNOME Mutter screws XWayland also screws Wine. However, I'd suggest doing the XEyes Test because this will tell you whether Wine windows are in fact Wayland or are XWayland. If they're XWayland, the reason they don't DPI right is obvious.
- Wayback not doing DPI right is surprising. I wonder if it has this problem in KDE. I wonder if that's a natural site for me to attempt contributing to Wayback.
"it rounds down" == no scaling support (has been the case in the past, should be long gone)
"it rounds up" == no fractional scaling support, only integer (not sure which setting you had to enable?? that was the ootb behavior for ages)
now if you enable the "secret" experimental setting (and by "secret" i mean it's been mentioned in 47 release notes),
gsettings set org.gnome.mutter experimental-features '["scale-monitor-framebuffer", "xwayland-native-scaling"]'
it will support fractional scaling on xwayland