Revisit #134 (DOMMatrix)

[hober]

Hi,

(I got here from w3ctag/design-reviews#463.)

During the WebXR Hit Test Module's TAG review, I thought it was weird that that module uses a Float32Array instead of DOMMatrix. That's apparently because the underlying WebXR spec uses Float32Array, and switching to DOMMatrix was considered in #134 and then dismissed. Has enough changed since 2017 to revisit this decision? All things being equal, it would be great if CSS, SVG, and WebXR all used the same matrix representation.

[Manishearth]

I don't know what the spec looked like when #134 was discussed, but switching to DOMMatrix doesn't make sense at all in the current state of the spec: Those Float32Arrays are meant to be consumed by WebGL.

We could expose a DOMMatrix attribute as well, but so far it's been unnecessary. The Float32Arrays are necessary and cannot be removed.

[toji]

This has been revisited a couple of times since #134 was closed, and there's never been a strong reason to switch to DOMMatrix. To give some context for that decision:

• While it would certainly be nice if the web had a single unified matrix representation using DOMMatrix doesn't actually provide WebXR users many benefits and in most cases would force more overhead onto the common use cases.
• WebXR is an API that is defacto paired with WebGL to produce it's visuals (with WebGPU being an eventual alternative) neither of those APIs deal with DOMMatrix directly, but do have multiple facilities for working with data packed in array buffers. In order to avoid unnecessary allocations and copies we felt strongly that it was best to match our APIs output with how we expect the data to be consumed.
• We expect that the matrix values from our API will almost never be used as inputs to CSS or SVG, so interoperability with those APIs is very low priority for us.
• DOMMatrix can represent any 4x4 matrix, but the interface is strongly skewed towards manipulating transformation matrices while one of our primary uses is projection matrices. Therefore there was not much functional benefit to packing the data that way.
• For users that do want to work with DOMMatrix, it's trivial to create one from the Float32Arrays that we return. This does incur a copy, but since we believe it will be the less common case that was deemed to be the better tradeoff.
• It's become less of an issue since then, but at the points that we were discussing our matrix representation DOMMatrix was still unimplemented or partially implemented in browsers that were interested in supporting WebXR. We did not want to introduce another hurdle to adoption at that time.

Additionally, we did leave open the possibility of adding DOMMatrix entry points if we see strong demand for them. The attributes that surface the matrices today can be lazily evaluated and alternate forms of the data could easily be surfaced at little to no cost. (For example, a lazy domMatrix attribute can be added alongside the matrix attribute on the XRRigidTransform interface.) Thus far, however, this issue is the only time we have heard any feedback from the community over our matrix representation since shipping. Most people seem pretty happy with the current API structure.