[PATCH 2/2] protocol: Add buffer_scale to wl_surface and wl_output

[Alexander Larsson]

On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
> Output scaling should be merged with the existing "buffer_transform" 
> (the 8-value enumeration describing 90 degree rotations/reflections).

In effect they are parts of the same thing, yeah. I don't know if ABI
compat allows us to just change buffer_transform though.

> I think in the end Wayland is going to have to have arbitrary affine 
> transforms in the api, and it might make sense to decide a standard for 
> these now, so that they are not split up amoung several apis like what 
> is happening now. Apparently there is worry about using floating point 
> in the api, but I think the following proposal that only uses integers 
> or fixed point works:
> 
> Translation are given as 2 24.8 fixed-point numbers.
> 
> Scale is 4 unsigned numbers: w,h,W,H. You can think of these as the size 
> of the source and destination, or w/W and h/H are the scaling factors.
> 
> Rotation and skew are 4 integers: x0,y0,x1,y1. The X and Y axis are 
> rotated to point at these positions. To avoid skew use x1==-y0 and 
> y1==x0. Flipping the signs can be used to make reflections.
> 
> This setup allows some useful numbers with somewhat intuitive results, 
> and avoids trying to specify irrational numbers using integers.

I'm not sure this generality is useful for this? When would you ever
store the pixel data for your window pre-skewed? I mean, I don't think
in practice its ever gonna useful to have windows displayed rotated and
skewed on the screen, but I can see the conceptual nicety in allowing
this (i.e. wobbly windows with input working). But I don't *ever* think
an app is gonna supply the surface data for the window in such a way.