- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Feb 2017 11:41:54 +0000
- To: public-device-apis-log@w3.org
We certainly need to be moving in a direction where we distinguish
*polling frequency* from *reporting frequency*.
For low-level motion sensors, which are essentially going to be used
as below (so *without* event handlers), I think we should make
*polling frequency* settable and be more than a hint (but be clamped
to HW values, obviously).
```js
let gyro = new Gyro({ pollingFrequency: 120 });
function display() {
requestAnimationFrame(function() {
document.getElementById("foo").innerText = `x: ${gyro.x}, y:
${gyro.y}, z: ${gyro.z}`;
display();
});
}};
```
We'd also need sound default values for `reporting frequency` in such
a case.
If we move towards supporting BYOB for motion sensors, we'll need to
think of *reporting frequency* in terms of "your buffer is full and
needs to be swapped."
I like how you're thinking about these two different frequencies once
in term of *update frequency* and once in term of latency.
I'd probably argue for thinking about it differently (and I have use
cases to back it up that I still need to write up), but I think we're
converging here. :)
--
GitHub Notification of comment by tobie
Please view or discuss this issue at
https://github.com/w3c/sensors/issues/152#issuecomment-279685591 using
your GitHub account
Received on Tuesday, 14 February 2017 11:43:34 UTC