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.