[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

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).

>> 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.

>> 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.