[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

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?

So that compositors are allowed to only keep the cropped area of a 
buffer, there will have to be limitations on changing the crop+scale 
without also doing another attach. Maybe it does not work unless there 
is an attach in the same commit, or you might even require the attach to 
be after the crop+scale and before the commit.

The big problem I see with this api is that if buffer_scale is not one, 
the client is unable to specify the crop or scale rectangles in pixels. 
However this is a general problem with buffer_scale everywhere. 
(actually you seem to be using fixed, not integers, so it is possible if 
buffer_scale is a power of 2). I would change the crop to be in pixels. 
The scale rectangle requires fixing or replacing the buffer scale mechanism.

You need to define what happens if the crop region extends outside the 
buffer. I think the edge pixels will have to be replicated to fill, 
since using transparency here will turn an opaque buffer into one with 
transparency, and produce an anti-aliased transparent edge, both of 
which may defeat the ability to use hardware scaling.

I think there may also have to be rules about whether filters are 
allowed to sample outside the crop region (there are things other than 
box filters, you know). For security reasons this must not be allowed 
outside the actual buffer, so that adjacent memory does not leak into 
the displayed image, but it could be left undefined for pixels between 
the crop and the buffer edge.