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

[Pekka Paalanen]

On Fri, 29 Nov 2013 01:51:03 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
> 
> On 26 November 2013 17:19, Jonny Lamb <jonny.lamb at collabora.co.uk>
> wrote:
> > +      <arg name="src_x" type="fixed" summary="source rectangle x"/>
> > +      <arg name="src_y" type="fixed" summary="source rectangle y"/>
> > +      <arg name="src_width" type="fixed" summary="source rectangle
> > width"/>
> > +      <arg name="src_height" type="fixed" summary="source
> > rectangle height"/>
> 
> In the same vein as my reply to Bill, I'd really like to see these
> changed to int. I have little sympathy for clients which perform
> layout such that their buffer_scale doesn't allow them to represent
> their scene in integer space.  I also have a very difficult time
> imagining that toolkits would actually perform layout like this.
> 
> The more practical / less ideological objection is that this is an
> invitation for clients to get things very, very wrong.  Using fixed
> suggests that partial-pixel co-ordinates are okay (e.g. src_x of 8.5
> with a buffer_scale of 3); just how this is supposed to be represented
> accurately in hardware, I'm not quite sure.  I don't see any benefit
> to this additional complication for both protocol and implementations;
> only downsides.

Err... but arbitrarily fractional values are technically ok. As I
explained before:

On Wed, 27 Nov 2013 10:34:10 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

GL-renderer has no trouble realizing fractional src rect values; if I
read compositor-drm right the drmModeSetPlane() API uses 16 bits for
the fraction, and even rpi Dispmanx uses 16.16 fixed point. The way
pixman renderer is written it should handle fractions just fine, too.

If I understood anything from v4l2, it seems to leave the matter up to
each driver or device.

The test program included in the series deliberately has 1px wide
green lines in the buffer, which are cut in half by using fractional
values to test it. With a 1x1 linear texture sampling filter (pixman and
gl renderers) this results in the surface edge being solid green and
shifting to blue when moving towards an inner pixel, just like it
should. Checking visually with xmag, the results look identical.

You're right that I don't know of any real world use case where
fractional src rect is needed, but since all the hardware APIs I know
about have it, I guess it is useful for something. Therefore I
included it.

My imaginary use case is a pointer-controlled magnifier, where if the
magnification is high enough, pointer motion can move the src rect in
less than one buffer pixel steps.


Thanks,
pq