[RFC] wl_surface scale and crop protocol extension

[Bill Spitzak]

Jason Ekstrand wrote:

> Agreed.  Sending transform matrices or the like has HUGE rounding 
> problems.  Particularly when we're using wl_fixed which is 24.8.  Other 
> methods would require adding rounding conventions etc.

I was assuming IEEE 32-bit floating point would be in the api for at 
least the ABCD of the matrix (the XY could be wl_fixed I suppose).

However what you call "rounding conventions" are needed even for the 
proposed integer api, and this is also why a source rectangle is needed. 
It has nothing to do with inaccuracy. It is because filtered needs to 
know it, since the filter will extend outside the source region (it will 
for down-scales for any reasonable filter, and even for up-scaling for 
mitchell/sync style filters). Samples outside this region must be 
treated specially and this "rounding convention" must be defined by 
wayland (almost certainly you want to define it as using the nearest 
pixel inside the region).

So yes a source rectangle must be provided in the api, but not for the 
reason you think. The destination rectangle is then a nice way to 
produce rational fractions for scale and also provide a wl_surface size 
that is different than the buffer size.

I would make one change to the proposal because I think arbitrary 
transforms will need to be considered some day. The source rectangle has 
to remain orthogonal in source space (otherwise it is useless for 
filtering), while the destination has to be orthogonal in "surface 
space" (since it also controls a lot of other wl_surface details), 
therefore any future arbitrary transform must be between these. I think 
the current "buffer transform" should be considered the start of any 
future arbitrary transform, so for that reason the source rectangle 
should be in actual buffer pixels, not in "buffer transform space".