Pekka Paalanen wrote:
Or would you rather have src_x, src_y, src_width, src_height always
defined in buffer coordinates, and then buffer_transform and
buffer_scale (with their requirement of size being a
multiple of buffer_scale) applied to dst_width and dst_height instead?
In the latter case, the surface size would be affected by all of
buffer_transform, buffer_scale, dst_width and dst_height.
The source rectangle *must* be in buffer pixels. Putting it in
buffer_scale units makes absolutely no sense, as the buffer_scale is in
effect ignored for this surface, overridden entirely by the scaling.
It does not matter whether buffer_transform is applied first, as it does
not move where integers are.
Also if integers are used it is impossible to scale an image that is not
a multiple of buffer_scale in both dimensions. Using fixed for the
source rectangle works around this problem but is very misleading.
At the moment it sounds like the destination has to be in buffer_scale
units, rather than in pixels, in order to match the rest of the Wayland
api. I think this is a mistake but it should be fixed everywhere, not
just here.
In the end, I see no other difference between the transformation orders
than convenience: calculations you might be able to avoid, some lines
of code you can skip writing. The same piece of code has to control both
the wl_surface interface and the wl_surface_scaler interface anyway.
In theory yes, but unfortunately in the real world there is finite
precision in our representation of numbers, making the differences
relevant and important.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
