Re: [sensors] Batching API for sensor readings

> I was planning to have an internal data structure that is being 
fulfilled periodically (using a timer) with N latest readings starting
 from the moment when collectLatestReadings() is called and till the 
moment when next frame paint is scheduled (i.e. right before rAF 
callbacks are invoked) and in the later moment the internal data 
structure contents would be copied to the given Float64Array. Thus 
client has a notion of previous readings obtained with the frequency 
higher than the current frame rate.

That seems perfectly reasonable.

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

Would you handle the use case of collecting large amounts of data 
(e.g. 500 samples at 120 Hz) using the same API?

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?

> In Chromium sensor data is fetched from the underlying system in one
 process and then it is put to a shared memory buffer. JS runs within 
a different process.

> Considering the fact that JS engine can arbitrary pause or defer 
scripts execution I doubt that we can completely avoid sample loosing 
whatever API we invent.

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.

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

Received on Friday, 24 February 2017 14:17:09 UTC