On Mon, 13 May 2013 19:02:34 -0700 Bill Spitzak <spit...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel