Re: comments on Matrix

On Wed, Mar 20, 2013 at 2:30 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:

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

Obviously, we're not ignoring this :-)


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

I hope that we can address them in the near future.


> and hearing that some of these mistakes are copied from other,
> already-blessed Web APIs is even more discomforting.
>

What you call a mistake (QR decomposition) is a well documented, fast
alternative (I know at least 3 now that use this).
>From the paper you quoted:

Also, the algorithms for QR are simple and efficient. The drawback is that
the orthogonal matrix
extracted is not particularly meaningful: it is not independent of the
coordinate basis used, and so has no
“physical” significance


This implies that the QR algorithm is fast but it doesn't produce results
that you should use directly.
So, we should use it for matrix interpolation but not to get the decomposed
values out.


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