A Specification for Wayland Fractional Scaling

Closed lb90 requested to merge lb90/wayland-protocols:client-based-fractional-scaling into main

Currently Wayland clients are only aware of integer scaling factors. Compositors can then implement fractional scaling by taking the image data and applying downscaling to render at the desired final size. However, client by themselves are not aware of the post-processing done in the compositor.


The technique of compositor-side texture scaling has seen wide adoption and is in fact already implemented by many Wayland-based compositors. However there are two major downsides to that method:

  1. Performance / Energy loss: Clients have to render to very big textures, which impacts drawing performance. The compositor then has to downscale the textures, which adds other processing. Ideally, both those two operations can and should be avoided.
  2. A bit blurry graphics: Downscaled graphics can end up looking somewhat blurry. Generally that's not a problem for graphical items, but poses a real problem for text, which instead should look very crisp.


The proposed specification aims to solve both these issues by building on top of what we already have. The proposal is to add a way for clients to

  • a) Request the final physical (non-virtualized) dimensions of a surface from the compositor
  • b) Tell the compositor that the client is able to render at the final dimension by themselves, thereby making any compositor-side scaling unnecessary.

This is a simple yet effective way to address the major issues of fractional scaling as implemented today in Wayland. I'd also like to cover some use-cases that may not be covered by the proposed functionality. For that, please, see the following paragraph.


Open a comment for any question / topic and continue the discussion in sub-comments (a thread). I'll add a list of all the discussed topics here in the following list:

Edited by lb90

Merge request reports