[RFC v2] surface crop & scale protocol extension

[Bill Spitzak]

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.