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

Re: [sensors] Batching API for sensor readings

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Fri, 24 Feb 2017 16:02:10 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-282328541-1487952129-sysbot+gh@w3.org>
> The given array will contain only the readings recorded while a 
single frame painting, meaning that for 120 Hz polling frequency (and 
assuming 60 fps) space for 2 readings should suffice.

What happens when we fall below 60 Hz, though? I think we need to 
account for that in how we size buffers (or the underlying data 
structure used to populate them.

> Instead, maybe we could require array size equal to [READING_SIZE * 
COUNT+1] and the last element will be used as a flag indicating 
overflow, so that the user can allocate a bigger buffer for the next 
time.

I imagine that if we can write this info to the consumer's buffer, we 
can equally write it somewhere else and use that info to fire a 
"bufferoverflow" event, no? Seems more web-y. Events are synchronous, 
so the consumer would be informed within the same AF.

>>Would you handle the use case of collecting large amounts of data 
(e.g. 500 samples at 120 Hz) using the same API?
>The given array will contain only the readings recorded while a 
single frame painting, meaning that for 120 Hz polling frequency (and 
assuming 60 fps) space for 2 readings should suffice.

So that doesn't fit our Navisens use case. Would be interesting to 
thing about it separately, maybe even in terms of a 
ServiceWorker-based API, that would emit events a much longer 
intervals, once a large buffer would be full.

-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/171#issuecomment-282328541 using
 your GitHub account
Received on Friday, 24 February 2017 16:02:19 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:53 UTC