Re: comments on Matrix

On 21/03/2013, at 7:44 AM, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:

> 
> Mostly because we think this is a common enough use case that it shouldn't need external libraries.
> 
> That's a good criterion for including stuff --- but not the only criterion, not an absolutely sufficient condition.

I agree it isn't a sufficient condition.

> 
> It has to be balanced with other criteria:

Let's examine WebGL or WebAudio against your criteria (note that I'm a big fan of both APIs)

>  - is this something for which there exists a consensual choice of API? No, matrix APIs are hard to get people to agree on.

Both WebGL and WebAudio would not pass here.

>  - is this something that has a well-defined wanted feature set? No, every matrix library has a different feature set and I don't agree with the feature set that this one currently has.

Both WebGL and WebAudio would not pass here.

>  - is this something that we can hope will perform significantly better if implemented inside of the browser? No, as said above, quite the contrary.

For WebGL and WebAudio it is the only option. For this matrix class, as I said in the other email, this will perform orders of magnitude faster than the current code (which is parsing strings). Sure, other solutions might be faster (but will require loading a JS library).

>  - is this something that we are confident won't incur a large maintenance load? No, if this becomes popular we will have to make it run fast and that will be a rathole as explained above.

Both WebGL and WebAudio impose orders of magnitude more maintenance load on browsers than this API.

>  - is this something that people here on this mailing list / WG know better than application developers do? No, being a browser developer doesn't make one good at matrix libraries.

If you follow that logic, then only the best person in each field should be allowed to do something. It's also why the W3C process requires the request of public comments. All APIs are compromises. As has been mentioned many times now, this is not intended to be the one-matrix-library-to-rule-them-all, and is not intended to be a core part of JavaScript.

The goal here is to make the lives of CSS and SVG developers better, and to expose the functionality they already get through transforms. I actually argued against having the decomposition method, and would be ok with it being removed. But otherwise the objective is so that instead of:

function rotateMyObject(element, delta) {
  var currentTransform = window.getComputedStyle(element).transform; 
  // ouch, that's a matrix string... i need to somehow convert it to an object i can use
  // ... time passes
  var currentTransformMatrix; // suppose I did that
  // now I need to rotate it...
  // I either use some library or do it by hand
  // ok... now to set the transform...
  element.style.transform = "matrix3d(" + currentTransformMatrix.array[0] + ", " ......
  // note the above will have to go through the CSS parser, etc
}

Developers could do:

function rotateMyObject(element, delta) {
  element.style.transform = window.getComputedStyle(element).transformMatrix.rotate(delta);  // the API to get the typed matrix isn't actually this
}


It would be nice if we could come up with something that would address our goals, and also expose a Float32Array so any external matrix library can do things better/faster/whatever.

Dean