On 22/03/2013, at 7:22 AM, Gregg Tavares <gman@google.com> wrote:

On Thu, Mar 21, 2013 at 1:14 PM, Dean Jackson <dino@apple.com> wrote:

On 22/03/2013, at 4:14 AM, Gregg Tavares <gman@google.com> wrote:

I don't think using emscripten to compile C++ to JS is really the answer. Rather I see the examples that emscripten and asm.js suggest for perf that means you can could write a JS library that gives you the perf you want.

I'm absolutely against having a Matrix library built into the browser. It won't fit most use cases. It will be slower than ones like glMatrix. It will end up being cruft in the browser with a maintenance burden that means people will have to spend time on it when they could be spending time on more useful features.

There already is a matrix library built into the browser. We can't remove it. What the proposal on public-fx is trying to address is this:

1. Avoid the EXTREMELY costly conversion to/from a CSS string representation for CSS and SVG transforms

Returning and accepting a Float32Array solves this problem efficiently

2. Produce an API that is compatible with the existing, implemented and unchangeable Matrix API that's in the browser

Deprecate that API.

3. Given that 2 has some convenience methods for 2d transforms on matrices, and we're seeing lots of people do the same with 3d (but using strings!), extend the API to cover basic 3d transform operations

No reason to do this if you deprecate that API

4. Be at least as fast as a pure JS approach (or comparable for typical uses)

Not a goal if there is no matrix object.

5. Be built-in (no external download)

Not a valid goal IMO. By this argument you might was well build all _javascript_ in the entire world into the browser.

Despite arguing at length on the public-fx list, I'm very open to coming up with *any* solution that addresses the points above satisfactorily. If we can produce something that is helpful to WebGL as well, that would be awesome. But I'm getting the impression from this thread that you'd prefer custom JS libraries, which is fine. In which case, this API is irrelevant to you (and maybe the naming is the issue - should it be prefixed?).

It's not irrelevant though Putting a matrix library in the browser will encourage using it. When developers run into its limits they'll have to write their own anyway. They'll first try to wrap or enhance the built it one but the conversions to and from those objects will kill perf. Eventually they'll realize they need to do it all in JS. At which point, having exposed this Matrix library was a huge waste of time. A waste for browser devs. A waste of time for webpage devs.

In other words, since this API is an extension of something that already exists in the browser, it's not making WebGL content do anything different, and you're free to chose whatever solution you want.

Also note that the proposal isn't even an official public draft yet, so it can go through massive changes.

Dean

On Thu, Mar 21, 2013 at 9:54 AM, Brandon Jones <bajones@google.com> wrote:

On Thu, Mar 21, 2013 at 9:40 AM, Benoit Jacob <bjacob@mozilla.com> wrote:

Can't you just create a typed array view on the part of the heap ArrayBuffer that is of interest to you?

Yes, although you have to ensure that the heap pointers are aligned on 4 byte boundaries (assuming you're using floats). Not sure if emscripten's allocation systems would allow for that nicely. Do you have any insight on that?

--Brandon

Re: [Public WebGL] Matrix objects in JavaScript