- From: Simon Taylor via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Jan 2023 10:58:56 +0000
- To: public-device-apis-log@w3.org
@anssiko - I know your comment was now a few years ago, but can you remember if there was any movement on this at the F2F? As @robman explained really well, I think for me the main issue is missing readings if the main thread was too busy for a period of time. With WebGL on the main thread then things like loading model files or uploading large textures can block the main thread for hundreds of milliseconds. Another case to consider is if your regular WebGL render function takes 20ms or so, you end up regularly missing readings in that case. Exposing sensors to Workers might allow a better QoS for these cases, but having a dedicated worker for it seems like overkill if a batch delivery / recent reading history API could be added to the spec. On iOS Safari, the DeviceMotionEvent and DeviceOrientationEvents are queued for each reading, so if the main thread is busy you'll still get all the callbacks fired when the thread frees up again. If the rate is going to stay limited for privacy reasons to 60Hz then just adding the data into the events and queueing them would be a fine solution. Otherwise a rolling buffer of the latest readings accessible from the the Sensor instance would cover all of these "main thread too busy" issues. The buffer wouldn't need to be huge so I don't think the memory concerns would be a problem in practice - 200 samples or so should be more than enough for most temporary disturbances. -- GitHub Notification of comment by tangobravo Please view or discuss this issue at https://github.com/w3c/sensors/issues/13#issuecomment-1401734828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 January 2023 10:58:58 UTC