Re: [w3c/gamepad] Make gamepads accessible by web worker (#37)

> (Unless the event API is meant to replace the polling...?)

It would make polling less necessary in worker, but not replace it on the main thread (at least, we can't remove polling without "breaking the web"™️). However, as @reillyeon does reminds us, the @tkodw is making the case that applications "will prefer to access gamepad data from workers instead" (https://github.com/w3c/gamepad/issues/37#issue-177528094).

So, some options to consider:

1. Add the eventing model, but only on main thread: not good, because canvas has been transferred to worker 👎.
2. Don't add eventing model, but expose Gamepad API (polling) in Worker: This is ok, but we need to make sure user activation still works (it should, in theory). 
3. Expose Gampad API in worker, but only expose add eventing model. Question: is the polling API sufficient for all the gaming use cases? 
4. Expose Gampad API in worker and the eventing model: is it worth it, from an implementation perspective, to add the events if all the use cases are covered polling? Or is the eventing model of such advantage to developers that it outweighs the standardization cost? 

Would love to hear thoughts/pros and cons! 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/37#issuecomment-1135376670

You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/37/1135376670@github.com>