- From: Marcos Cáceres <notifications@github.com>
- Date: Sun, 19 Nov 2023 19:51:07 -0800
- To: w3c/gamepad <gamepad@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/gamepad/issues/37/1818184809@github.com>
Thanks @norren for sharing your experience. It certain adds weight to the argument and you are right that because of where the canvas is being rendered (off screen) and the close relationship between what is being rendered and user input, it does throw weight behind the argument that *something* is needed here. The situation is somewhat unique, in that we have forced developers into this situation precisely with postMessage() and SharedArrayBuffer, and I have to agree on a person level... that kinda sucks. The argument about realtime access to inputs VS events is a little bit beside the point (the use cases can be met by either). I think browser vendors will tend to lean towards an eventing model (and an effort has been underway to make gamepad API more event based, with "live" objects #8). And even if one had "immediate" access to the state of some input device, as a developer you can't actually be guaranteed that it's not a cached value. I can't promise this won't take another 7 years to fix, but we definitely need to have another serious conversation about this if postMessage and SharedArrayBuffer are causing noticeable issues. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/gamepad/issues/37#issuecomment-1818184809 You are receiving this because you are subscribed to this thread. Message ID: <w3c/gamepad/issues/37/1818184809@github.com>
Received on Monday, 20 November 2023 03:51:12 UTC