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

Re: [Public WebGL] Matrix objects in JavaScript



The issue of allocations and jittery animations is something that concerns CSS transforms as well. If you want as smooth as possible JS driven animation then allocating new objects to transform things will lead to issues of animation quality if you do it 60x per second. So if it's relevant to WebGL or not as a functionality, the suggestion to make copy-free semantics possible applies all the same.


On Thu, Mar 21, 2013 at 9: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
2. Produce an API that is compatible with the existing, implemented and unchangeable Matrix API that's in the browser
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
4. Be at least as fast as a pure JS approach (or comparable for typical uses)
5. Be built-in (no external download)

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

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