Add support for fractional scaling
Fractional scaling in Wayland has been discussed in various places, most recently in #34, but has never had a dedicated tracking issue. This issue is supposed to fill this gap.
The current Wayland protocol allows clients to scale their buffers by an integer scale factor, matching the integer-scale defined for each output and therefore allowing their surfaces to be displayed at reasonable scale even on High-DPI displays.
The restriction to integer scale factors however is a big issue when the ideal scale factor for best usability falls in between two integers.
Example: On my 32" 4K display I would consider a scale factor of 1.5 to be ideal. At a scale of 1 text becomes too small to read, while a scale factor of 2 wastes screen real-estate.
A second issue with integer scale factors is, that matching the scale of multiple outputs with different DPI values is not possible.
Example: A common setup with this problem is a 1080p and a 1440p monitor of the same size next to each other.
Current implementations like Gnome, KWin, wlroots fake fractional scaling by providing clients with the next-highest integer scale factor for each output and then downsizing the received buffer during compositing. This approach comes with two major problems:
-
Since the client renders into a larger-than-native buffer there is a significant performance overhead, which is especially noticeable in graphics intensive applications such as games.
Example: on a 4K (3840 × 2160) display with an optimal scale factor of 1.5 a game might render at 5K (5120 × 2880) resolution requiring 78% more pixels than necessary to be rendered. -
Downscaling causes aliasing artifacts, reducing the quality and sharpness of the image. This is especially noticeable with text rendering. Advanced text rendering techniques such as subpixel-rendering are completely impossible.
For these reasons there needs to be a Wayland protocol extension that allows clients to render at a fractional scale and provide buffers at native resolution.
Fractional scaling needs to be opt-in for clients, so that existing applications are not affected.
In #34 (comment 785418) it was proposed to start the implementation of this with a demo for a full-screen client.