On Thu, 02 May 2013 12:16:23 -0700 Bill Spitzak <spit...@gmail.com> wrote:
> 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). If you looked at the Wayland specification, you'd see that there are no floats. > 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). That's not a rounding convention. Rounding convention is about converting real numbers into integers, and I really meant that. Not filtering. And I really do *not* want to specify a filtering method at *any* level, because whatever we specify, there will always be hardware that does it differently. I will not write down any guarantees of the resulting quality, or the scaling method used, because I do not want to exclude any scaling hardware. > 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. My reason for using a source rectangle is because I want to be able to crop. > 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". What chip do you have in mind, that can do arbitrary matrix-based transforms during an overlay scanout? - pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel