[PATCH weston 4/8] protocol: crop & scale RFC v3

[Bill Spitzak]

On 11/27/2013 12:34 AM, Pekka Paalanen wrote:
> On Tue, 26 Nov 2013 12:47:07 -0800
> Bill Spitzak <spitzak at gmail.com> wrote:

>> (swap order of clip+scale and buffer_scale)

> I have explained all this before. Nothing here has changed.

I realize this but I still have to express my complete dumbfoundment 
that you think this is ok.

The client is going to want to line up the dst rectangle with pixels in 
the parent surface's buffer, and this prevents that unless the 
buffer_scale is one.

I believe the reason is that you are concerned with displaying a 
high-buffer_scale surface on a low-output_scale device. I think however 
it will be ok to round the dst rectangle to what the hardware can do 
(adjusting the source so the same scale is achieved). Also this 
limitation seems silly if the user only has the high-resolution output 
device and thus never needs it!

> The "smear" is exactly the same as "random-colored" from the protocol
> point of view. What you get depends on the compositor implementation,
> just like the method used for scaling (only ever using NEAREST is not
> illegal!). If you care about how exactly these things are done, you need
> to scale it yourself in the client first.

I may have been too wrong to say the result cannot be "undefined". I 
only want to prevent bright random dots. An output pixel that is 
supplied by a filter that only partially intersects the buffer can be 
filled by any of the following:

  - A solid color such as black or transparent. The second is what I am 
forced to do currently with the api by truncating the dst rectangle 
instead of rounding it.

  - The non-intersecting part of the filter samples black or transaprent 
or any other solid color

  - The non-intersecting part of the filter samples the nearest edge pixel.

  - The non-intersecting part of the filter is mirrored to sample inside 
the edge.

Pixels where the filter does not intersect the buffer can be transparent 
or black. I suspect this is the main reason you want to say "undefined", 
since an obvious implementation is to intersect the source rectangle 
with the buffer and adjust the destination rectangle to match.

>> Distorting the picture is not an acceptable solution
>
> You mean you do not want the compositor to stretch the image slightly
> differently than what the client explicitly requested? I agree, but
> there may be cases where that would mean losing a hw overlay and
> causing a big performance loss.

Distortion required by limits in the hardware is acceptable. But 
distortion caused by limits in the api is unacceptable and that is what 
I am trying to fix.

> The values are allowed to be arbitrary, so that you can zoom in to
> partial buffer pixels if you want to. They are not meant to counter
> buffer_scale, which you will likely choose to set to 1 anyway when
> using crop & scale and regardless of output scale.

You are correct that the buffer scale is useless and can be left at 1. 
It would be useful if the dst rectangle was before it.

I am still assuming that somebody will realize that there is a desire to 
line up the dst_ rectangle with the pixels in a parent buffer with a 
buffer scale that is not one. In this case the buffer scale is useful.