On Thu, 2 May 2013 09:42:42 -0500 Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen <ppaala...@gmail.com> > wrote: > > > On Tue, 30 Apr 2013 10:54:25 -0500 > > Jason Ekstrand <ja...@jlekstrand.net> wrote: ... > > > On Tue, Apr 30, 2013 at 2:33 PM, Pekka Paalanen > > > <ppaala...@gmail.com> wrote: > > > ... > > > > This interface allows to define the source rectangle > > > > (src_x, src_y, src_width, src_height) from where to take the > > > > wl_buffer contents, and scale that to destination size > > > > (dst_width, dst_height). This state is double-buffered, and is > > > > applied on the next wl_surface.commit. > > > > > > > > Before the first set request, the wl_surface still > > > > behaves as if there was no crop and scale state. That is, no > > > > scaling is applied, and the surface size is the buffer size. > > > > > > > > On compositing, source rectangle coordinates are evaluated > > > > after wl_surface.set_buffer_transform is evaluated. This means > > > > that changing the buffer transform and correspondingly the > > > > client rendering does not require sending new source rectangle > > > > coordinates to keep the exact same image source > > > > rectangle. In other words, the source rectangle is given in the > > > > not-scaled-and-cropped surface coordinates, not buffer > > > > data coordinates. > > > > > > > > > > I agree with Zhi, this needs to be re-worded > > > > Yeah, did you understand what I was trying to explain? Any > > suggestions? > > > > If I understood correctly, you meant the sensible thing. i.e., > buffers are in (possibly transformed) buffer coordinates while > surfaces are in surface coordinates. In other words, the crop/scale > is applied after the buffer transform. How about this (actually a > paragraph higher): > > The source rectangle is specified in (possibly transformed) buffer > coordinates. This means that changing the buffer transform and > correspondingly the client rendering does not require sending new > source rectangle coordinates. In other words, the source rectangle > is given in the coordinates that the surface would have without the > scaled-and-cropped transformation. This is a little better, avoids "evaluated", but still I wonder if we could separate buffer coordinates and orientation-transformed buffer coordinates better. We have: A. Buffer pixel coordinates, which are essentially equivalent to byte addresses of pixels in the buffer. apply buffer transform to get: B. oriented buffer coordinates (I wish I would have suggested the term "orientation" when the buffer transform was proposed, now we have several "transformations".) apply crop & scale to get: C. surface coordinates, i.e. the local coordinates where all window management and input happens And the rest is private to a compositor. Before crop & scale, C was equal to B, and now it is not. If we just had a term to use for B consistently, describing everything would be a lot easier. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
