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

[Bill Spitzak]

Fractions are required so that a client can get the same scale in both 
directions for a destination that is not square, or to get the same 
scale for different crops of the destination rectangle.

Also all hardware must do this if it is capable of cropping the output, 
since a cropped subrectangle of a scaled rectangle is equivalent to 
scaling from a fractional source rectangle to that crop rectangle.

On 11/28/2013 05:51 PM, Daniel Stone 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.
>
> Cheers,
> Daniel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>