Re: [sensors] Batching API for sensor readings

> 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