[PULL] Matrix inversion and tests v1

[Pekka Paalanen]

On Mon, 16 Jan 2012 21:19:32 -0500
Kristian Høgsberg <krh at bitplanet.net> wrote:

> On Mon, Jan 16, 2012 at 10:20 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > Hi Kristian,
> >
> > this patch series implements inversion for 4x4 matrices, specifically
> > for struct weston_matrix. It comes with a test application for both
> > correctness and performance.
> 
> Hi Pekka,
> 
> The series look good, I like where it's going.  I cherry-picked the
> build fix for now (btw, I don't get the error, I don't even get a
> warning, not sure what's going on...).
> 
> I'll hold off on merging the series for a little bit yet.  Right now
> I'm trying to stabilize the code toward a snapshot release in a couple
> of weeks.  If that gets unbearable, I'll just branch it and we can
> continue feature work on master, but for now I'll just try to cool
> down master a bit.

Cool!

> The other thing is that I'd like to see this series concluded with
> actually using the transform for converting input and damage
> coordinates.  Maybe we can even do a test-case where we can rotate or
> scale a surface and verify that the input events and damage are
> processed correctly.

Yup, I had such test cases in mind. Weston rotating a surface
will be a pretty hard test on all aspects related to surface
transformations. I just wish we had an easy way to verify the
damage region accounting...

Maybe an idea from Compiz, where each painted rectangle is tinted with
a semi-random color.

> > From these we can infer, that if we need to use the inverse matrix for
> > more than 7 point transformations, we are better off computing the
> > inverse matrix explicitly first. Total time for invert and transform N
> > points is, in theory:
> >
> > - explicit inverse: 190 ns + N * 29 ns
> > - weston_matrix_invert: 90 ns + N * 44 ns
> >
> > That is for my machine, and of course ignoring possible precision
> > problems.
> 
> Very nice, very thorough work.  I'm thinking that we probably want to
> just always go fo the explicit inverse though.  Typically, we'll
> always need a few inverse transformation (pointer motion typically
> comes in bursts) and I don't think we have a pattern where we need to
> continuously update the matrix and then only compute a couple of
> transform for each matrix.And I much prefer to keep it simpler and
> just have the one matrix type.

Agreed.

> Right, the series as it is now can't cause any trouble, but I'd like
> to see a few more patches to actually switch us over to using the
> transforms.

Sure, that's what I am doing next.


Thanks,
pq