[RFC] wl_surface scale and crop protocol extension

[Pekka Paalanen]

On Thu, 2 May 2013 09:42:42 -0500
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Thu, May 2, 2013 at 5:51 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> > On Tue, 30 Apr 2013 10:54:25 -0500
> > Jason Ekstrand <jason at jlekstrand.net> wrote:
...
> > > On Tue, Apr 30, 2013 at 2:33 PM, Pekka Paalanen
> > > <ppaalanen at 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