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

[Pekka Paalanen]

On Mon, 13 May 2013 19:02:34 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> Alexander Larsson wrote:
> 
> > On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
> >> 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.
> 
> I think it may be useful for clients to compensate for odd transforms 
> that a compositor applies to thumbnails, etc. They could produce a much 
> higher-fidelity image by drawing the transformed image directly. The 

One could, but we don't.

> compositor would tell the client "I am applying this transform to this 
> surface" and the client could re-render the surface using that transform 
> and set the inverse as the transform. The compositor would then multiply 
> these to get an identity and know that it does not have to apply any 

You cannot get an identity by multiplying real-valued transformations
together, other than by accident. Also, we still do not have any
floating point formats in the protocol, making transmitting these in
the first place a pain.

> transform to the surface. In fact this is exactly how the 
> buffer_transform works today. (ps: the compositor would only report the 
> fractional part of xy translate, thus preserving the "clients don't know 
> where the windows are" design feature).

buffer_transform works like this only, because the transforms are
enumerated, and therefore accurate in the strict mathematical sense.

> It won't help for wobbly windows unless "transform" is much more 
> complicated that just the 6-number affine I propose. But at least being 
> able to describe a transform as a single object means that it may be 
> possible to enhance it this way in the future.

No.


- pq