Re: Low Latency User Input

+1 from here as well, I’m all for expanded functionality 🙂

Ironically, I don’t think my use case would be benefit from this (don’t
think I can’t paint faster than rAF() on the main thread), but higher
precision access is a plus nonetheless

Sincerely,


Christopher Rodriguez

Founder, GamePad Viewer


On Wed, Jan 17, 2024 at 9:49 AM Vincent Scheib <scheib@google.com> wrote:

> And CC +public-games@w3.org <public-games@w3.org> for more awareness of
> work to improve user input latency.
>
> On Wed, Jan 17, 2024 at 9:45 AM Vincent Scheib <scheib@google.com> wrote:
>
>> Chiming in with my support for this!
>>
>> On Mon, Jan 15, 2024 at 4:48 PM Marcos Caceres <caceres_m@apple.com>
>> wrote:
>>
>>> Hi Carl,
>>>
>>> Thanks again for taking the time to outline the issues. I’ve proposed
>>> this as a topic for the upcoming W3C Breakout day (12th of March):
>>> https://github.com/w3c/breakouts-day-2024/issues/2
>>>
>>> Details for the W3C Breakout day are here:
>>> https://github.com/w3c/breakouts-day-2024
>>>
>>> Hopefully we can get the right folks in a virtual room to discuss some
>>> options and a path forward.
>>>
>>> Kind regards,
>>> Marcos
>>>
>>> > On Dec 9, 2023, at 13:51, Carl Younger <carl.joseph.younger@gmail.com>
>>> wrote:
>>> >
>>> > Hey guys,
>>> >
>>> > Despite many advances in recent years, the Web remains a poor choice
>>> of platform for any application that depends on responding to user input
>>> with low latency.
>>> >
>>> > The APIs that handle user input (keyboard, pointer, gamepad, HID, USB,
>>> MIDI, Bluetooth, serial etc) generally require registering handlers on the
>>> main thread. As the main thread is often busy, handlers cannot (reliably
>>> and consistently) respond to input with low enough latency for certain
>>> applications.
>>> >
>>> > Affected applications include any video game that demands precise
>>> inputs (which is a large subset), pretty much all DAWs and synthesizers, as
>>> well as art programs that use touch gestures to emulate brushstrokes etc.
>>> >
>>> > The situation might be improved somewhat by extending input APIs to
>>> include timestamps, but exposing the APIs to Web Workers is a much better
>>> solution.
>>> >
>>> > Some of the input APIs can extend their spec to support workers
>>> relatively easily, and there has been some progress there already
>>> (including some implementation). Other APIs are more problematic. For
>>> example, keyboard and pointer events are part of the DOM API, which marries
>>> them to the main thread.
>>> >
>>> > I recently discussed all this with Marcos Cáceres (and others). Marcos
>>> advised me to contact this mailing list, as I feel that these issues will
>>> require a macroscopic perspective (beyond the scope of any specific API)
>>> and a substantial community effort to address.
>>> >
>>> > Thank you for taking the time to consider my post.
>>> > Much appreciated -- Carl
>>> >
>>> > The original conversation: github.com/w3c/gamepad/issues/37
>>>
>>>
>>>