[RFC] wl_surface scale and crop protocol extension

[Pekka Paalanen]

On Thu, 02 May 2013 12:16:23 -0700
Bill Spitzak <spitzak at 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