Re: [sensors] Should the API allow setting both samplingFrequency and reportingFrequency?

> Would love to see if we have the same understanding of #209 (comment), now. :)

Sorry for the delay.
I think our `reporting Frequency` and Android's `maxReportLatencyUs` are a quite different things and one of them cannot be expressed through the other.

Android's maxReportLatencyUs is used as described below:

"The events can be stored in the hardware FIFO up to maxReportLatencyUs microseconds.
Once one of the events in the FIFO needs to be reported, all of the events in the FIFO are reported sequentially.
This means that some events will be reported before the maximum reporting latency has elapsed."

Setting maxReportLatencyUs to a positive value allows to reduce the number of interrupts the AP (Application Processor) receives,
hence reducing power consumption, as the AP can switch to a lower power state while the sensor is capturing the data. "

In our case, I propose the following terminology:

**sampling frequency**  is the frequency at which UA obtains sensor readings from the underlying platform (but these readings are not necessarily exposed to JS at the same rate).

**reporting frequency** is the frequency at which `onchange` is invoked (and possibly attribute values are updated) for a given JS `Sensor` object.

At the moment, by setting {frequency: .. Hz } the user actually sets the desired `reporting frequency` however s/he thus makes the UA to request a corresponding `sampling frequency` from the underlying platform.

**Reporting latency vs sampling frequency in options**

In Chromium (where JS runs in a different process) we use shared buffer to deliver sensor readings from platform side to JS. JS thread reads from this shared buffer at arbitrary moments causing some _extra latency_. Increasing of sampling frequency (i.e. the frequency at which sensor readings are written to the shared buffer) can reduce this extra latency, _but_ it might not be the case for _other_ UAs (in theory sensor notifications from platform could be received right in the JS thread). Therefore giving a `latency hint` would be a more generic API.

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

Received on Thursday, 1 June 2017 13:58:14 UTC