3 ms·

This is not limited to XWayland windows. See the relevant issues: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/34 https://gitlab.freedeskt

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.

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.