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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel