Re: [sensors] Batching API for sensor readings

> Would the buffer get overwritten each turn? Or just used once?

Only once per `collectLatestReadings()` call (this is gonna be an 
expensive method so IMO it's better to call it explicitly on every 
frame)

> 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.


> If so would we fire specific events when the buffer is full? What 
would happen to extra samples? Would they stay in your data structure 
until a new buffer came along?

Inside the internal data structure the oldest readings will be 
replaced by the new ones, so if the given buffer is shorter than 
needed it will contain the latest readings and the older ones will be 
lost.

Any new event will be delivered in a different call chain (at an 
undefined future moment) which means that some samples will be lost in
 meanwhile.. 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 guess in practice that depends on the size of the underlying 
shared buffer, no? I think if we can limit this to being really rare 
and/or fire readinglost events (but would we even know we lost data?),
 that would be neat.

JS is not aware if it got suspended or deferred so there is always a 
likelyhood of lost samples

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

Received on Friday, 24 February 2017 15:00:43 UTC