[RFC v2] surface crop & scale protocol extension
spitzak at gmail.com
Fri Nov 8 10:59:07 PST 2013
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.
More information about the wayland-devel