We are developing an in-browser racing game that relies heavily on gamepads and particularly complex racing wheels and pedals.
Given the differences in hardware, lack of support for Vibration and Haptic Feedback and pooling rather that event-based access, we decided to implement our control layer using WebHID instead of Gamepad API.
To be able to provide the lowest possible latency, we need to make sure the inputs are sent over to the backend ASAP (websockets in our case), without blocking the main thread, hence the need to access this API inside web workers is needed.
We see the same was done for service-workers (in extensions) in #97, so I assume this change is very similar and easy to add, the requestDevice should still reside in the main thread only.
Hope this is sufficient details for our use-case, otherwise we are happy for an open discussion, CCing @nondebug and @chengweih001 in.
Thank you in advance!
We are developing an in-browser racing game that relies heavily on gamepads and particularly complex racing wheels and pedals.
Given the differences in hardware, lack of support for Vibration and Haptic Feedback and pooling rather that event-based access, we decided to implement our control layer using WebHID instead of Gamepad API.
To be able to provide the lowest possible latency, we need to make sure the inputs are sent over to the backend ASAP (websockets in our case), without blocking the main thread, hence the need to access this API inside web workers is needed.
We see the same was done for service-workers (in extensions) in #97, so I assume this change is very similar and easy to add, the
requestDeviceshould still reside in the main thread only.Hope this is sufficient details for our use-case, otherwise we are happy for an open discussion, CCing @nondebug and @chengweih001 in.
Thank you in advance!