[RFC v2] surface crop & scale protocol extension
ppaalanen at gmail.com
Sun Nov 10 00:40:25 PST 2013
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.
More information about the wayland-devel