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