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

@Norren - Thanks for taking the time to lay out your experience with the API.

To be fair, the issues you're having with `postMessage` and shared array buffers are intrinsic to threads on a multicore system. You *must* use atomics to access shared memory whenever you have one thread writing to memory that another thread may be reading from, whether you implement something yourself (using shared array buffers and atomics) or use something higher level, like `postMessage` (which can be slow, as it copies data, rather than sharing it).

The issue here is that your user input is only available on the main thread, while you need code in another thread to respond to user input with low latency. If you could respond to input in the worker thread directly, your issues with concurrency wouldn't apply here.

@marcoscaceres - The current (DOM-based) Keyboard API wouldn't make much sense in workers, as events would be global (there's no DOM). Given that and the fact that multiple threads may want to handle keyboard events, it seems to me that the API should allow threads (including the main thread) to register listeners for specific keybindings.

You'd have to bikeshed an API (looking at prior art), but the basic idea is to allow a thread to bind a listener to, for example, <kbd>Ctrl</kbd>+<kbd>Enter</kbd>, ignoring other input (rather than binding to every key-down event, then filtering out the ones you don't care about in the callback).

This would be a better API in many cases, so code running exclusively on the main thread may still use it. The current API would not be made redundant though, as it's part of the DOM API (permitting listeners to be bound to elements etc).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/37#issuecomment-1821821770
You are receiving this because you are subscribed to this thread.

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