Row vs column major matrices

[nical]

Gecko and euclid's matrices are currently row-major. Web standards use column-major matrices.

@peterjoel proposed in issue #145 to make eulid matrices compatible with the web rather than gecko. I am filing this to keep it a separate discussion since issue #145 is about pre/post multiplications.

I personally think that there is more value in having all internal usage of matrices on the same convention. If/when WebRender makes it into gecko, all of the features are aren't supported (SVG for instance) will be gecko code. The prospect of starting to build a transform in rust-land with a certain layout, keep building it cpp-land with another layout and then debug that is not a happy one.
I am less worried about having to transpose matrices when exposing the DOM, because it happens at a separation between two very different worlds. I don't think I'll find myself hack bits of the rendering engine on both sides of a DOM interface at the same time while I can totally see the rendering engine becoming a mix of rust and cpp code.

So my (biased) opinion is that compatibility with gecko is more important.

That said I am looking into Gecko's matrices to see how dangerous it would be to change the transposition (ideally gecko, servo and the web would agree about matrix layout), so far I haven't come across a lot of code outside of Moz2D that make assumptions about the layout. I'll see what the rest of the gfx team thinks about changing it.

To give an idea of the different matrices involved:

• euclid: row-major
• moz2D: row-major
• cairo: row-major
• D2D: row-major
• skia: column-major
• web standard: column-major

[nical]

In case the column-major vs row-major thing confused anyone as much as it confused me, let's make things clear:

The convention is only a matter of how the elements of the matrix are stored in memory. Gecko/Euclid's matrices are not incompatible with web standard, since the standard does not dictate how elements are laid out in memory it only specifies how elements are stored in Float32Arrays when converting matrices to and from typed arrays. Gecko's DOMMatrix class is built on top of Moz2D's row-major Matrix classes after all. Whether the 14th element element in memory is on the last row or the last column is only a matter of how one chooses to represent the matrix in his head.

Euclid could just replace its to_array() methods with to_array_row_major() and to_array_column_major() to remove the ambiguity. Equivalent constructor methods in euclid would be nice too.

I personally don't think it is worth changing a lot of code for the sake of storing matrices column-major order.

[peterjoel]

Euclid doesn't use an array for storage, it uses lots of attributes; m11, m12, etc. Rather than having to remember to set m41 when we mean m14, we should probably create wrappers for both use cases, WebMatrix and GeckoMatrix. Changing the order of multiplication can be done behind this abstraction too, and it should be zero-cost with inlining.

[nical]

No, m41 means the same thing in row-major and column-major layouts. it is just at a different offset in memory. To create a translation you set m41, m42 and m43 both with euclid and with css matrices.

[nical]

I talked with the rest of gecko's gfx team and gecko is not going to change to column-major. It would be a lot of work for no benefit. having gecko and servo use different conventions to store matrices would only make it harder to debug, as soon as we are in gdb looking at our memory, so I think that it would be best for euclid to stay row-major. servo has to interface with row-major APIs in any case.

What I propose to make it easier is the following changes:

• Remove fn to_array(self) -> [T; 16] add fn to_row_major_array(self) -> [T; 16] and fn to_column_major_array(self) -> [T; 16].
• remove fn new(...) -> Self and replace with fn row_major(...) -> Self and fn column_major(...) -> Self.

The column_major versions would probably only be used in DOM code, and the rest would stick to the row_major interface they already use.

This way euclid matrices can be used with either mindsets as long as nobody tries to mem::transmute a matrix into a column-major thing, while the memory layout and the debugging story stays coherent.