Proposal: Use Gecko's convention for matrices. about euclid HOT 6 CLOSED

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

from euclid.

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).

from euclid.

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

from euclid.

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.

from euclid.

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

from euclid.

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

from euclid.