Re: comments on Matrix

2013/3/20 Dean Jackson <dino@apple.com>

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

I know WebGL, but not WebAudio, so I'm going to focus on that one.



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

I disagree --- WebGL decided early on to stay very close to OpenGL ES
precisely (among other reasons) to get quick consensus on API design, and
it's played out very well.


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

I disagree. "Let's expose the same feature set as OpenGL ES 2, minus
possibly a few ones that are tricky or out of place in a Web API, plus
possibly a few extensions" is very well-defined.


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

...and loading a JS library is not bad.
My point is if we really had to implement that, we'd be better off
implementing it in JS and shipping that JS code with the browser. Why not,
but before getting there I'd rather let competing matrix libraries (either
JS libraries or more realistically C++ libraries emscripten-compiled to JS)
shake it out --- we could reconsider bundling one in the future if it comes
out as the obvious winner.


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

Not proportionally to the services they offer, or the size of their APIs.
Getting this matrix API to run really fast without implementing in JS would
require JS-compiler-level tweaks, which WebGL doesn't require. Getting this
matrix API to run really fast by implementing it in JS and improving JS
compilers and asm.js would make more sense, but as said above, I believe
that the better course of action is to let JS developers use their favorite
one and keep improving the toolchains (JS engines, emscripten/mandreel,
asm.js...) to allow that to perform well.



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

I'm not saying that only the best person in each field should be allowed to
do something. I'm saying that some fields are specialist fields where it
takes a lot of full-time effort for anyone to even start making something
decent, and someone ignoring this will make basic mistakes, and even
someone spending lots of time will have a hard time generating consensus
around one's solution (there is no one-size-fits-all matrix library).

The current draft shows basic mistakes (by the way, most of my points in
the first email in this thread haven't been discussed yet --- I think only
points 2 and 6 have been touched on at all), and hearing that some of these
mistakes are copied from other, already-blessed Web APIs is even more
discomforting.

Benoit




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