RFC: Add a mechanism to wl_surface to communicate scale
I would like to propose adding an optional event/request pair to wl_surface
to suggest/describe the relative scale factor of the surface-local coordinate space. This has three main considerations.
- Adding
wl_surface.scale_factor
andwl_surface.set_scale_factor
to suggest/set the preferred/intended relative scale factor of a surface by setting
- the integer numerator, probably unsigned, of a ratio
- with a protocol-defined, sufficiently large, and possibly broadly divisible denominator
- with a protocol-defined nominal physical unit factor such that the scale is physically accurate to that unit if and only if both client and compositor use a scale equal to the pixel density of the output when applying this physical unit factor
- such that parent- and subsurfaces always share the same scale
- such that a scale factor of 1 corresponds to the widely used, entirely non-physical standard scale of "96 DPI pixels."
-
wl_output.scale
does not apply, and should not be sent, to clients using this protocol version. - To retain all the uses of
buffer_scale
, define a buffer superscale and a buffer subscale, both integral, that cannot both be defined. I suggest using positive and negative values ofbuffer_scale
respectively, with 0 and -1 invalid. A superscale is the factor by which the buffer is larger than the surface space, which is the current behavior ofbuffer_scale
. A subscale is the factor by which the buffer is smaller, meaning that that buffer is intended to be upscaled by that factor to match the surface space. This solution works very nicely together with !220 (merged).
The intent is to give compositors and clients enough information to make scaling decisions for themselves. This is sufficient to do so.
I am however aware that the discussion around scale and scaling, and especially the question of what scaling mechanisms the protocol should dictate, has been raging for many years with little progress made. I've found that the Chromium OS team have already implemented this concept as their Aura protocol, currently an extension to Wayland, complete with a compatibility layer called "sommelier" to fake and approximate as well as possible for Wayland and X11 clients. If even Google is that pessimistic about all things scale in core Wayland, I will set my own hopes accordingly.