W3C home > Mailing lists > Public > public-device-apis-log@w3.org > March 2017

Re: [sensors] Provide the DeviceOrientation sensor

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Fri, 03 Mar 2017 16:25:20 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-283999765-1488558319-sysbot+gh@w3.org>
> From a user point of view (user being front end dev or the like) - 
they will mostly care about the actual orientation values and know 
that the latency will be different between something connected and 
something external, but it is not like that they will drop using a 
headset because of latency issues, if what they care about is the 
headset orientation :-)

My understanding is key players in the industry are are worried about 
VR-induced motion sickness and thus would probably want to restrict 
usage for devices which don't meet certain latency requirements 
(motion-sickness correlates closely with latency).

The game industry is accustomed to running a bunch of tests to figure 
out if HW requirements for particular settings are met. I imagine the 
same will be done for VR.

> It is all about balance. If we say that these are super low level 
APIs and that libs need to be built around them to make the APIs 
consumable, well then we can very well get away with only having 
populate methods and nothing for the simple case, which you were 
arguing for :-)

I wasn't expecting the BYOB API to be synchronous, as unless the 
implementation is willing to always store all samples between two 
frames, then this API doesn't work for more than 1 samples (which is 
clearly a requirement).

Arguably we can have two BYOB APIs, but it might not be super 
API-consumer friendly to have one such API be sync (for 1 sample) and 
the other one async (for > 1 sample). But maybe it would be OK. I 
don't know.

If we go for a sync BYOB, we could also imagine the Typed Array as 
argument would be optional, so you could do:

interface VectorRotation : Sensor {
   Float32Array? read(optional Float32Array buffer);

Where read would either fill the the buffer you passed it or create 
one on the fly, e.g.:

let s = new VectorRotation({
    format: "quaternions",
    pollingFrequency: 120
let reading = s.read(); // null
// once sensor it activated
reading = s.read(); // Float32Array of length 5? we need a timestamp 
somewhere :-/
let buffer = new Float32Array(VectorRotation.QUATERNION_SIZE);
s.read(buffer); // buffer is now filled up with one reading.
// etc.

For > than 1 sample, we could imagine setting the buffer size in the 

let s = new VectorRotation({
    format: "quaternions",
    pollingFrequency: 120,
    bufferSize: 2 * VectorRotation.QUATERNION_SIZE
or through a dedicated method:

let s = new VectorRotation({
    format: "quaternions",
    pollingFrequency: 120
s.bufferSize = 2 * VectorRotation.QUATERNION_SIZE;

or even by passing a buffer upfront that's always overwritten (similar
 to the async version I had in mind):

let buffer = Float32Array(4 * VectorRotation.QUATERNION_SIZE);
let s = new VectorRotation({
    format: "quaternions",
    pollingFrequency: 120,
    buffer: buffer
buffer === s.read(); // true

There's a lot explore here, though. And some pretty important issues 
to consider, e.g. what happens when pollingFrequency < animation frame
 rate? Or when when frames slow down so you buffer gets more samples 
than it can handle? Where do you put timestamps? etc.

Half of the above are probably terrible ideas, but this area is 
certainly worth digging into seriously.

There's the potential to make something both powerful and 
user-friendly but also to screw it up badly and ship something that's 
over-engineered and crappy.

GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/170#issuecomment-283999765 using
 your GitHub account
Received on Friday, 3 March 2017 16:25:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:34:22 UTC