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".
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
