[PATCH 2/2] protocol: Support scaled outputs and surfaces

[Bill Spitzak]

Alexander Larsson wrote:

> You can make a surface of any integer size (and it has to be integer due
> to existing APIs on surface coordinates/sizes), however the *buffer* has
> to be an integer multiple of the surface size. In other words, surface
> sizes and positions are described in the global compositor space, with
> integer sizes.

This seems pretty limiting to me. What happens when *all* the outputs 
are hi-res? You really think wayland clients should not be able to take 
full advantage of this?

> If nothing else it makes it so that subsurfaces are
> always positioned on integer positions on non-scaled displays, which
> makes things easier when monitor of differen scales are mixed.

This is false if the subsurface is attached to a scaled parent surface.

> I see it the other way. We currently have *two* coordinate spaces that
> the client has to think about. The buffer coordinates (it has to know
> this when rendering), and the surface coordinates (these are basically
> what all wayland APIs atm use, like in damage, positioning and input).
> The transform between two is currently the buffer_transform only. With
> the buffer_scale the transform is extended to also scale, but no
> additional coordinate space is added.

The input rectangle to the scaler proposal is in the space between the 
buffer transform and the scaling. Therefore there are *three* coordinate 
spaces.

My proposal is that "surface space" be moved before the scaling. This 
reduces the number of spaces back to two by using the same space for 
input rectangle as for events and surface size, etc. It also means 
integers always have a physical meaning for the client (ie buffer 
pixels) and that odd-sized buffers are supported on the hi-res display.

The number of spaces could be reduced one more by moving everything to 
before the buffer_transform. However this would change existing wayland api.