On 11/27/2013 12:34 AM, Pekka Paalanen wrote:
On Tue, 26 Nov 2013 12:47:07 -0800
Bill Spitzak <spit...@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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
