[RFC v2] surface crop & scale protocol extension
spitzak at gmail.com
Mon Nov 11 10:47:47 PST 2013
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
> 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.
More information about the wayland-devel