[PATCH] protocol: Add buffer_scale to wl_surface and wl_output

[Bill Spitzak]

John Kåre Alsaker wrote:
> On Tue, May 14, 2013 at 2:51 PM, Alexander Larsson <alexl at redhat.com 
> <mailto:alexl at redhat.com>> wrote:
> 
>     On tis, 2013-05-14 at 13:44 +0200, John Kåre Alsaker wrote:
>      > I'd only accept a proposal which makes the clients tell the
>     compositor
>      > how much they increased the size of their window. If the compositor
>      > wants to resize anything it should resize the entire window and not
>      > individual surfaces/buffers. This also avoids having to position
>      > subsurfaces and have configure requests at fractional surface pixels.
> 
>     I don't quite understand what you mean by this (like, how is "window"
>     different from "surface"). Can you give an example of how the API would
>     look for what you mean.
> 
> A window can have multiple surfaces (see the subsurface extension).

I don't see any problem at all. Any scale being applied to a surface to 
be applied to it's subsurfaces as well. And subsurface position is in 
pre-scaled coordinates so if you want a subsurface to align with some 
pixels in the main surface's buffer, the position is still in integers.

Yes the subsurface's destination rectangle is going to be scaled to 
non-integers. I think you have to realize you are not going to avoid 
this problem by your attempt to link the clipping rectangle to the 
scaling factor. Clients should deal with it by rendering images such 
that the result is not objectionable, mostly by forcing the edges to be 
replicated on buffers, and filling the invisible areas with non-clashing 
pixel values.

I now do very much believe that the scaler extension should be altered 
so that surface size and events are reported in pre-scaled (ie in buffer 
pixels) coordinates. This makes the transformation be done at the same 
step as this scaler, reducing the number of different coordinate spaces. 
You cannot do it the other way because that *does* require surface sizes 
to be non-integers.