[geometry] Consider using Typed Arrays for matrices and static transform operations

[esprehn]

Existing code and WebGL represent matrices as a Typed Array, perhaps we should instead make the matrix operations be statics.

ex.

Float32Array = DOMMatrix.translate(Float32Array, Float32Array);

and the self() versions would modify one of matrices in place. This better matches the API surface available today and avoids having to indirect through DOMMatrix and then convert back into a Float32Array to use it with WebGL.

@bfgeek

[zcorpan]

This seems interesting but I think we should somehow keep compatibility with web content that uses WebKitCSSMatrix. That could be done by renaming DOMMatrix to WebKitCSSMatrix and specifying a new DOMMatrix that just has static operations for typed arrays... or we could add static operations to DOMMatrix as well.

DOMMatrix currently has fromFloat32Array() and fromFloat64Array() statics (and corresponding to* operations). In your proposal would it return a Float64Array if a Float64Array is passed in?

[chrishtr]

Another option is to make a new constructor to DOMMatrix that takes a Float64Array or Float32Array, and spec it to use that typed array as the backing store. e.g. multiplications in-place would update that array, the implementation would use it internally, and accessors like m11 etc would mutate that typed array.

It does seem to be the case that we could add support for typed array-backed methods in the future.

[foolip]

It'd probably be tedious (and slower) to have DOMMatrix use either a typed array of something else, so going this route, would it make sense to just say that DOMMatrix is backed by a Float64Array by default? Whether it was provided with the constructor or not, the backing array could then be exposed as an attribute on DOMMatrix. (But not on DOMMatrixReadOnly.)

[foolip]

That'd make DOMMatrix more like a wrapper around typed arrays, where the wrapper would probably require much more memory than the backing array itself. Static methods by the names name but with more arguments would still make sense I think.

[chrishtr]

Specifying a backing of typed array and exposing as a property could be done, but that wouldn't solve
the problem of using a shared or pre-allocated backing. But I think this suggestion is backward-
compatible, so it could be added later.

[foolip]

We could of course leave DOMMatrix instances alone and have new static methods as the only way of working with typed arrays. I have no strong preferences.

[chrishtr]

Right exactly. To me, the important point is that it could be added later.

[dirkschulze]

The idea here was to have an easy and straight forward way to get values from DOM to WebGL and vice versa with fromFloat32Array and fromFloat64Array (now). IMO that is good enough for now.

[zcorpan]

Those methods create a copy though, so while it might be good enough for now, it's not optimal.