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.l...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
