[RFC v2] surface crop & scale protocol extension

[Pekka Paalanen]

On Fri, 08 Nov 2013 18:04:33 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 
> 
> Rafael Antognolli wrote:
> > On Fri, Nov 08, 2013 at 10:59:07AM -0800, Bill Spitzak wrote:
> >>
> >> Pekka Paalanen wrote:
> >>> Hi all,
> >>>
> >>> this is the v2 of the crop and scale extension, as RFC.
> >> I get the impression that the result of crop+scale is supposed to be exactly
> >> the same as though the client made a second buffer of the scale size, scaled
> >> the crop region from the first buffer to this second buffer, then attached
> >> it with the normal wayland mechanism. Correct?
> > 
> > From what I understood, the visual result might be that, but it's not
> > what should go on inside the renderer.
> 
> Sounds right. My main concern was that the scale width+height completely 
> replaces all uses of the buffer width+height in the visible compositor 
> api (the buffer width+height is needed to figure out where the memory 
> for the crop region is, but should be ignored otherwise).

This thread is about protocol. It says nothing about Weston's
internal implementation details.

> >> So that compositors are allowed to only keep the cropped area of a buffer,
> > 
> > IMHO the compositor would keep the entire buffer, just like it already
> > does.
> 
> I'm probably using shm too much but I thought it would be a savings if 
> the compositor could upload only the crop region to an EGL texture from 
> an shm buffer, and then immediately release the buffer.
> 
> I suppose it could upload the entire thing but then scaling the 
> subrectangle either requires a copy to another texture, or what I think 
> is an unrequired EGL extension. Scaling the entire thing but scissoring 
> the output does not produce the correct filtering at the edges.

No, there is no copy or EGL extension needed.

> >> You need to define what happens if the crop region extends outside the
> >> buffer.
> > 
> > It's defined as "undefined/dirty" pixels, isn't it? I think that's good
> > enough for now, at least.
> 
> I think making the crop larger than the buffer will be useful, 
> especially to fit your video into a slightly-different shaped window 
> (this will happen if the scale factor is not an integer). It may be 
> useful for letterboxing as well, but that will require the client to add 
> black pixels on the edges so the user does not just see the edge of the 
> video smeared to fill the area.

No, sampling outside of a buffer is a non-fatal client mistake.

- pq