Re: [sensors] Provide the DeviceOrientation sensor

Not sure why you'd need to wrap stuff? Can you be more specific? Also,
 afaik, constructing regular arrays is cheaper than Typed ones.
Say I wanted to use glMatrix or WebGL, then I would have to construct 
an array myself from properties. Same the other way around, if we 
expose it as say an object, and I wanted to use say DOMMatrix, then I 
would have to construct a DOMMatrix directly from the values, which is
 basically a wrapper around the pure values.

Sure, but this comes with extra GC issues which don't exist otherwise 
and which need to be handled via BYOB-type APIs which aren't exactly 
trivial.
BYOB is fine with me as it also scales to buffered values. But maybe 
we can expose something array like instead, now that you can make 
objects iterable (generators) etc.

There's seems to be multiple different ways to represent matrices 
using (typed|regular) arrays (including nested structures). Which ones
 should we pick and why. Where are they specified it at all.
We are talking about NxN array here, actually mostly 4x4 though 3x3 is
 valid as well. DOMMatrix and WebGL treats arrays like 
row1+row2+row3+row4. They are not multidimensional arrays, 
1-dimensional - continuous memory region.

The rest of the platform considers that to be a feature. Why is this 
not the case here? :P
History and first time user convenience, I would say :-)

Those are often objects you only use a few off (in comparison, at 
least), thus memory and performance is less important than user 
convenience. It is not really a bottleneck and the APIs are easier to 
grasp at first. I see that changing though, and developers are 
becoming more used to typed arrays (they are new and came with WebGL 
and now part of JS).

As a user, an Float32Array feels just like a regular JS array.

Now I would argue that an API with getters like x, y, z is easier to 
grasp as first, but due to WebGL, Web Bluetooth and other formats 
which have to efficiently transfer data, these use (typed) arrays and 
thus, being able to directly use these data the same way actually 
provides better developer convenience.

Also, I seldom use just one set of (x, y, z) - it is common to use 
lots of values and do math on top. At that point having them in a 
collection (like an array ;-)) is quite useful. Luckily most 
vector/matrix/quartenion math is easy to implement directly on top of 
arrays and arrays makes it easy to convert one type to another... 
sometimes you can just interpret data in a slightly different way.

I don't really think we can make the case for working well with 
certain JS libs as a Web standard. With Web Assembly perhaps a bit 
more so. Can you explain precisely how this WA-based modification 
would work?
I would assume that I will be able to more or less directly modify the
 typed array values in C/C++ as regular C/C++ arrays.

>From http://webassembly.org/getting-started/js-api/

Since most byte-range operations in JavaScript already operate on 
ArrayBuffer and typed arrays, rather than defining a whole new set of 
incompatible operations, WebAssembly.Memory exposes its bytes by 
simply providing a buffer getter that returns an ArrayBuffer. For 
example, to write 42 directly into the first word of linear memory:

new Uint32Array(memory.buffer)[0] = 42;
I assume that will mean that I can access the same Float32Array via 
memory from C++.

-- 
GitHub Notification of comment by kenchris
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/170#issuecomment-283100435 using
 your GitHub account

Received on Tuesday, 28 February 2017 17:03:49 UTC