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

[Pekka Paalanen]

On Fri, 29 Nov 2013 10:20:18 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

Ookay, so far it is just me vs. Daniel on the wl_fixed_t issue. Any
other opinions for/against changing wl_fixed_t to just int?


Thanks,
pq