[RFC weston 13/16] compositor: Add a function to test if images transformed by a matrix should be bilinearly filtered

[Pekka Paalanen]

On Fri, 03 Oct 2014 11:36:16 -0500
Derek Foreman <derekf at osg.samsung.com> wrote:

> On 03/10/14 02:04 AM, Pekka Paalanen wrote:
> > On Thu, 02 Oct 2014 17:21:04 -0500
> > Derek Foreman <derekf at osg.samsung.com> wrote:
> > 
> >> On 02/10/14 02:37 PM, Jason Ekstrand wrote:
> >>>
> >>> On Oct 2, 2014 12:37 AM, "Pekka Paalanen" <ppaalanen at gmail.com
> >>> <mailto:ppaalanen at gmail.com>> wrote:

> >> For gl-renderer, I suspect I need to build it myself in draw_view():
> >> weston_matrix_init(&foo);
> >> weston_matrix_multiply(&foo, &ev->surface->buffer_to_surface_matrix);
> >> if (ev->transform.enabled)
> >> 	weston_matrix_multiply(&foo, &ev->transform.matrix)
> >> weston_matrix_multiply(&foo, &output->matrix);
> >>
> >> Is that right?  Do I have the order backwards?
> >>
> >> I'd like to test just that one matrix and no additional if
> >> (ev->tranform.enabled) etc to decide on whether to use linear or nearest...
> > 
> > I can't bother to think far enough to say anything about the order
> > right now, but all this is what Weston core should be computing when
> > you're done (maybe a helper function called from renderers). So the
> > generic computation would be moved from pixman to core, and then only
> > pixman specifics are left in pixman renderer.
> 
> The really lovely part about pixman is that (if I'm "getting" it
> correctly) you transform the source image instead of transforming
> destination vertices.  So pixman needs things exactly backwards.

Yeah, backwards sounds familiar. Just reverse the polarity... err,
invert the matrix. It's only 3x3 at that point, and pixman can
probably do it. We can optimize it later if needed. Or if it looks
like the inverse form is more popular in general, we could just
construct that to begin with. Later. :-)

> >>>> The rpi-renderer uses pretty much the same as what DRM planes/overlays
> >>>> offer wrt. coordinates, IIRC: integer position and size on the output,
> >>>> and 16.16 fixed point position and size on input (buffer).
> >>>>
> >>>> Whether scaling factor is integer or not is irrelevant there. I do not
> >>>> recall there being an option for sampling (nearest/linear/...) in
> >>>> either DispmanX nor DRM.
> >>
> >> I think rpi has horizontal and vertical flip capabilities as well?
> >>
> >> I don't think that's exposed by drmModeSetPlane.
> > 
> > You clip by setting the source rectangle to smaller than the buffer.
> 
> Ahem.  Flip.  Not clip.  :D

Oops, yes. I'm not aware of flip support in DRM yet. :-)
I never really looked for it, either...

The whole point of buffer_transform is to let the buffer and output
flips/rotation match, so that apps could get directly scanned out
and on overlays.

Flips on rpi/DispmanX are possible, but because they do not work in
buffer space but the output space, using them properly got so hairy
I didn't get it right when I tried.


Thanks,
pq