[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Matrix objects in JavaScript

On 13-03-21 05:16 PM, Rik Cabanier wrote:

On Thu, Mar 21, 2013 at 1:56 PM, Gregg Tavares <gman@google.com> wrote:

On Thu, Mar 21, 2013 at 1:48 PM, Rik Cabanier <cabanier@gmail.com> wrote:

On Thu, Mar 21, 2013 at 1:22 PM, 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

It does not.

It does
Not only with it likely be slower than an object,

It will be faster in JS.

Which one is faster:
element.style.transform = window.getComputedStyle(element).transformMatrix.rotateBy(45); // 1 temporary object. all calculations on c++ side
... make sure some js library is loaded
element.style.transform = new MyMatrix(window.getComputedStyle(element).transform).rotateBy(45).getFloatArray(); // 2 (or 3) temporary objects + 6 or 16 (12 or 32?) temporary floats + all calculations on js side
it is also much harder for authors to use since they will have to rely on external matrix libraries or roll their own.

I don't agree. Almost all JS today uses lots of library. jQuery, require, etc... There's also the advantage that having it be an external library means developers and update it as fast as they want and not be stuck waiting for a browser vendors to add new features to Matrix.
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.

That is really not an honest response.
Most graphics libraries offer some sort of abstraction of a matrix class. Having the same available in your browser is not unreasonable.

Most graphics libraries have a very large math library designed for perf. They also have libraries designed for their language, usually C++.
They don't have some poorly designed matrix object with poorly designed legacy features

What is poor about the design? If it's the legacy SVG stuff, unfortunately it's something we have to carry around.

As long as the current badness is called SVGMatrix, I have some level of hope/confidence that it won't spread too much outside of code really using SVG, because using something named SVGMatrix for something that has nothing to do with SVG would sound like a hack and raise red flags in many developers' heads, or even, not occur to them.

But the moment you introduce a new W3C spec (even a working draft) in 2013 (so it doesn't look like old cruft) and have it called "Transformation matrix interface" and have it expose an interface that goes by the sweet name of "Matrix" and have existing Web-facing APIs updated to interface with it --- suddenly the natural, default reaction to it is to assume that it's recommended to use, that it's the blessed Matrix API of the Web.

If you renamed this Matrix interface to DeprecatedMatrix I would find it much easier to accept that we need this because of existing sadness in SVG or elsewhere.


and mixed up 2D and 3D features.

I admit I don't like that either. Would you prefer that it's split into 2 classes?

As pointed out else where, having a Matrix object is the wrong solution for _javascript_. The same as OS level kernel function calls instead of templated C++ would be the wrong solution for C++.


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.

The vast majority of needed matrix manipulations are well known.
If needed, people are free to roll their own. We should make sure that the API allows authors to do this efficiently.


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.


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?