- 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