5 ms·

> But I don't think that's Wayland's fault - it's up to those apps to upgrade their UI libraries (which might be a monumental task, I'm not sure). Actually, it

> But I don't think that's Wayland's fault - it's up to those apps to upgrade their UI libraries (which might be a monumental task, I'm not sure). Actually, it is Wayland's fault[0], and arguably Xorg is able to handle it better[1]. Basically, the protocol doesn't currently support sending a fraction as the scale to the application, so whenever you've got displays with DPIs that are not integer multiples of one another, the compositor will scale down on at least one of those displays, causing blur. In Xorg, it is normal for applications to simply detect the DPI of the display they're on and render accordingly. In either case, it requires support from the graphical framework used by the application (eg, Qt applications seem to automatically handle this on Xorg). I would quite like to replace one of my monitors in a multi-monitor setup with a HiDPI one, but lack of support for this is what's holding me back. I'd be happy enough if Firefox just added support to Xorg for DPI detection[2], though if Wayland gets this working first, I'll probably switch over to that (I've gone back and forth between Xorg/xmonad and Wayland/sway, and I don't really see any other blockers for me). [0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... [1] https://www.reddit.com/r/kde/comments/lficfe/wayland_fractional_scaling_may_be_sort_of_a/ https://www.reddit.com/r/kde/comments/lficfe/wayland_fractio... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1679335 https://bugzilla.mozilla.org/show_bug.cgi?id=1679335

3np 4y ago
This is currently working fine for me with the wayland backend (not xwayland) on Firefox in sway. The details escape me but I think it started working properly since a release during the past ~6-9 months. BTW, as a fellow long-time xmonad user who never managed to get fully used to the i3/sway tiling model I've been very happy so far switching to Qtile on my X11 machine. Took a couple of hours to replicate my decade-of-custom-crust Xmonad setup and another couple to add some new nice stuff I either wasn't able to or never bothered with (scratchpad/dropdowns for my top 5 frequently used apps like chat,pavucontrol,music,dashboards has already been a productivity improvement). It seems to be on good track to work well in native Wayland mode as well, meaning we can have the same WM on both :)
- maxdamantus 4y ago
  Right, the effective DPI switching works for Firefox on Wayland, but like all other applications on Wayland, fractional scaling will result in blurriness. I was looking into this less than 6 months ago, and I don't see any relevant updates since then and can see various other recent reports of the same issue. The main applications I use are Firefox and some terminal emulator, so I would be happy as long as I can get both of those working using fractional scaling on either of Wayland/Xorg (without downscale blurring). It doesn't work in Wayland due to limitations in the protocol and it doesn't work in Xorg simply because Firefox haven't implemented it there (and they seem to have closed the issue as WONTFIX, telling people to use Wayland instead, which has this issue that GGP raised). It does work specifically in Xorg in Qt applications, though I don't actively use any of those.
  - 3np 4y ago
    output $MONITOR scale 1.25 in sway; no blurriness. IIRC the only thing I eventually did to make things work was setting env vars MOZ_ENABLE_WAYLAND=1 MOZ_WAYLAND_USE_VAAPI=1 (You probably already know this but check `window protocol` under about:config and/or use the xeyes method to verify that it's indeed not falling back to Xwayland. I mention this because any time I experienced blurriness, Xwayland's been in the loop and xeyes is a quick way to check that for any app) As for terminals: foot has some weird behavior with font sizes[0] but kitty and alacritty have not had surprises here so far (though I didn't try alacritty in multi-DPI situation yet) [0]: https://codeberg.org/dnkl/foot/issues/714 https://codeberg.org/dnkl/foot/issues/714
    - maxdamantus 4y ago
      I really don't think this is correct. It is possible that you're just not able to notice the blurriness due to the scaling method used, the resolution of the display and the fact that text rendering tends to be blurred nowadays anyway [0], but I'm 95% sure that you'll be looking at blurred output, as documented [1]: > An integer is recommended, but fractional values are also supported. If a fractional value are specified, be warned that it is not possible to faithfully represent the contents of your windows - they will be rendered at the next highest integer scale factor and downscaled. I've just tried it again myself and can observe the downscaling. I can provide screenshots later demonstrating the scaling artifacts if anyone is really interested. [0] I configure my systems to perform crisper font rendering using `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, along with some extra fontconfig options. This results in glyphs being aligned with actual pixel boundaries, reducing the need for antialias blurring. [1] https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc607a6797919c8cf341/sway/sway-output.5.scd https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc60...
nyanpasu64 4y ago
Frankly I'd be happy with integer window scaling and fractional font scaling (like Xft.dpi, progress at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...).
kaba0 4y ago
I’m fairly sure it only happens on XWayland windows, and that in general it is not possible to fractional scale something without the aid of the client. OSX also has a similar restriction where only integer scaling is allowed (but it is less of a problem there due to higher resolutions in general). There is fractional scaling though under Wayland which works fine for Wayland applications.
- maxdamantus 4y ago
  This is not limited to XWayland windows. See the relevant issues: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... It turns out there has been some activity recently, but this seems to all be in the form of draft PRs: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... You are correct in saying that it requires support from the client. This is even the case for integer scaling, which is why it's unfortunate that there's a protocol and clients that are specifically designed around integer scaling without addressing fractional scaling.
  - tadfisher 4y ago
    Integer scaling has already been implemented and doesn't result in pixel-snapping artifacts and broken text rendering. I fear that fractional scaling will result in exactly this, similar to CSS 1.0. The OSX solution is the only one that will avoid insane complexity at all levels (protocol, compositor, and client), and as demonstrated by OSX, can work fine in a mixed-DPI environment.
    - maxdamantus 4y ago
      The problem is that this is what currently happens when people enable fractional scaling (ie, setting the scale to 1.5 rather than 2), which I'm fairly sure is common. Try running a web browser with fractional scaling, open up a JS console, and look at the values for `devicePixelRatio` and `innerWidth`. You'll probably see that the former is an integer (particularly, the ceiling of your configured scale, eg, 2), and the latter is wider than the actual number of device pixels. This means the web browser is rasterising to a larger size and then being downscaled. Unless the rasterisation size is an integer multiple of the final pixel size (which it's not), there will be unavoidable "pixel-snapping artifacts". This is basically the whole premise behind vector graphics. You wouldn't use a bitmap font that's been scaled down to the right size, but this is effectively what happens when viewing text on Wayland with a non-integer scale.

3np 4y ago

This is currently working fine for me with the wayland backend (not xwayland) on Firefox in sway. The details escape me but I think it started working properly since a release during the past ~6-9 months. BTW, as a fellow long-time xmonad user who never managed to get fully used to the i3/sway tiling model I've been very happy so far switching to Qtile on my X11 machine. Took a couple of hours to replicate my decade-of-custom-crust Xmonad setup and another couple to add some new nice stuff I either wasn't able to or never bothered with (scratchpad/dropdowns for my top 5 frequently used apps like chat,pavucontrol,music,dashboards has already been a productivity improvement). It seems to be on good track to work well in native Wayland mode as well, meaning we can have the same WM on both :)

maxdamantus 4y ago
Right, the effective DPI switching works for Firefox on Wayland, but like all other applications on Wayland, fractional scaling will result in blurriness. I was looking into this less than 6 months ago, and I don't see any relevant updates since then and can see various other recent reports of the same issue. The main applications I use are Firefox and some terminal emulator, so I would be happy as long as I can get both of those working using fractional scaling on either of Wayland/Xorg (without downscale blurring). It doesn't work in Wayland due to limitations in the protocol and it doesn't work in Xorg simply because Firefox haven't implemented it there (and they seem to have closed the issue as WONTFIX, telling people to use Wayland instead, which has this issue that GGP raised). It does work specifically in Xorg in Qt applications, though I don't actively use any of those.
- 3np 4y ago
  output $MONITOR scale 1.25 in sway; no blurriness. IIRC the only thing I eventually did to make things work was setting env vars MOZ_ENABLE_WAYLAND=1 MOZ_WAYLAND_USE_VAAPI=1 (You probably already know this but check `window protocol` under about:config and/or use the xeyes method to verify that it's indeed not falling back to Xwayland. I mention this because any time I experienced blurriness, Xwayland's been in the loop and xeyes is a quick way to check that for any app) As for terminals: foot has some weird behavior with font sizes[0] but kitty and alacritty have not had surprises here so far (though I didn't try alacritty in multi-DPI situation yet) [0]: https://codeberg.org/dnkl/foot/issues/714 https://codeberg.org/dnkl/foot/issues/714
  - maxdamantus 4y ago
    I really don't think this is correct. It is possible that you're just not able to notice the blurriness due to the scaling method used, the resolution of the display and the fact that text rendering tends to be blurred nowadays anyway [0], but I'm 95% sure that you'll be looking at blurred output, as documented [1]: > An integer is recommended, but fractional values are also supported. If a fractional value are specified, be warned that it is not possible to faithfully represent the contents of your windows - they will be rendered at the next highest integer scale factor and downscaled. I've just tried it again myself and can observe the downscaling. I can provide screenshots later demonstrating the scaling artifacts if anyone is really interested. [0] I configure my systems to perform crisper font rendering using `FREETYPE_PROPERTIES=truetype:interpreter-version=35`, along with some extra fontconfig options. This results in glyphs being aligned with actual pixel boundaries, reducing the need for antialias blurring. [1] https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc607a6797919c8cf341/sway/sway-output.5.scd https://github.com/swaywm/sway/blob/445bc2a943d905a0e5b1dc60...

nyanpasu64 4y ago

Frankly I'd be happy with integer window scaling and fractional font scaling (like Xft.dpi, progress at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i...).

kaba0 4y ago

I’m fairly sure it only happens on XWayland windows, and that in general it is not possible to fractional scale something without the aid of the client. OSX also has a similar restriction where only integer scaling is allowed (but it is less of a problem there due to higher resolutions in general). There is fractional scaling though under Wayland which works fine for Wayland applications.

maxdamantus 4y ago
This is not limited to XWayland windows. See the relevant issues: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i... It turns out there has been some activity recently, but this seems to all be in the form of draft PRs: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... You are correct in saying that it requires support from the client. This is even the case for integer scaling, which is why it's unfortunate that there's a protocol and clients that are specifically designed around integer scaling without addressing fractional scaling.
- tadfisher 4y ago
  Integer scaling has already been implemented and doesn't result in pixel-snapping artifacts and broken text rendering. I fear that fractional scaling will result in exactly this, similar to CSS 1.0. The OSX solution is the only one that will avoid insane complexity at all levels (protocol, compositor, and client), and as demonstrated by OSX, can work fine in a mixed-DPI environment.
  - maxdamantus 4y ago
    The problem is that this is what currently happens when people enable fractional scaling (ie, setting the scale to 1.5 rather than 2), which I'm fairly sure is common. Try running a web browser with fractional scaling, open up a JS console, and look at the values for `devicePixelRatio` and `innerWidth`. You'll probably see that the former is an integer (particularly, the ceiling of your configured scale, eg, 2), and the latter is wider than the actual number of device pixels. This means the web browser is rasterising to a larger size and then being downscaled. Unless the rasterisation size is an integer multiple of the final pixel size (which it's not), there will be unavoidable "pixel-snapping artifacts". This is basically the whole premise behind vector graphics. You wouldn't use a bitmap font that's been scaled down to the right size, but this is effectively what happens when viewing text on Wayland with a non-integer scale.