Proposal: Use Gecko's convention for matrices.

[nical]

Rather than detailing all of the differences, I encourage you to look at Gecko's matrix classes.

It is terribly dangerous to have Servo and Gecko use different conventions for matrices. Especially since the plan is to share more code in the future. Unless there are very good reasons for euclid's matrices to be the way they are, it is more realistic to change Servo than Gecko for obvious reasons (feel free to ask if you want to argue about that).

Also gecko's matrix multiplication works a lot more naturally with units when building transforms up, because Mat<A,B> * Mat<B,C> * Mat<C,D> = Mat<A,D> which reads nicely from left to right, while euclid goes Mat<C, D> * Mat<B, C> * Mat<A,B> = Mat<A, D>. But honestly, the massive interop foot-gun between servo and gecko is what terrifies me.

This is a much bigger change than the units discussion. Basically everything in servo that uses matrices is affected in non-trivial ways.

I apologize for my "We gotta change everything" attitude between this proposal and the other one. I hope that there will be more direct cooperation between gecko and servo devs (at least on the gfx side) and it simply cannot go well if the basic math structures that are all over the rendering engines aren't compatible between the two. I also believe that gecko's math is well battle-tested by now and has grown into a better design than euclid (in the way units are handled and other things that I haven't nagged you about yet).
As a (meager) consolation, I am willing to help with implementing these changes as opposed to just starting bikesheds.

[nical]

cc @SimonSapin, @glennw, @pcwalton, @metajack, @asajeffrey, @nox
Big topic. I wish I had looked into these before MozLondon.

[nical]

Hm, I delved a bit and I realize the issue is not as I bad as I thought: the only convention difference is in the order in which transformations are expressed (A = B x C vs A = C x B). The resulting matrix is laid out the same way gecko and servo which means the interop issue is only that gecko devs may mistakenly write a.mul(b) when writing they should write b.mul(a) in servo code. When I filed this I though the matrix layout was not the same which mean creating a matrix in gecko and pass it to webrender would be incorrect (which was terrifying).

May bad. That said, having the same conventions in gecko and servo would really help if we are to share more code so my proposal still holds.

In short: change the order of multiplications: a.mul(b) would produce the equivalent of what b.mul(a) does currently, and translate/scale/etc. would turn into pre_translate/post_translate/pre_scale/etc. to avoid making mistakes (servo's current operations are pre_ operations).

[glennw]

Changing the order of the operations to match what gecko does sounds good to me!

[peterjoel]

I don't know anything about Gecko, but the Euclid matrix layout is different from the w3c geometry specifications. For example, this geometry specification uses the last column for translation, while Euclid uses the last row.

There may be more value in compatibility with specifications than with Gecko.

[pcwalton]

I don't really have much of an opinion either way.

[nical]

I have a branch [1] on top of the units work, with pre- and post-operations exposed explicitly (I even removed mul in favor of pre_mul/post_mul). It also has row-major and column-major interfaces implemented to help with interfacing with the DOM or whatnot (cf. issue #146), and I added a lot of the missing documentation.

Feedback very welcome. So far my impression is that nobody is opposed to what I propose here. Other people in the gfx team also expressed that it would be nice to have familiar interfaces in euclid (about the pre and post transforms).
I'll make a pull request if/when the units stuff moves forward (I'm confident I'd mess up rebasing two dependent PRs).

[1] https://github.com/nical/euclid/blob/pre-post/src/matrix4d.rs