[w3c/gamepad] Arbitrary buffering of API calls is causing issues (#46)

In many current implementations of the Gamepad API calls to getGamepads does not make API calls to the OS to get updated gamepad state and instead return stale data.

Chrome has an arbitrarily chosen polling rate of 16 ms that applies to all platforms.
https://cs.chromium.org/chromium/src/components/exo/gamepad.cc?sq=package:chromium&dr=C&rcl=1478013686&l=36

Firefox has an arbitrarily chosen polling rate of 50 ms (!!!) for windows.
https://dxr.mozilla.org/mozilla-central/rev/2c773b97167252cedcba0be0c7af9d4cab192ef5/dom/gamepad/windows/WindowsGamepad.cpp#51

A very common OS + Gamepad configuration is probably Windows with an Xbox One or Xbox 360 controller. Both of those controllers have drivers that poll internally at 8 ms intervals by default.

In Chrome's case, since the internal polling rate is half of the gamepad polling rate, half of the updates from the controller will be lost.

With this configuration, buffering API calls adds additional latency of up to 24 ms on Chrome and up to 58 ms on Firefox.

You can test this yourself with a joy to key program. With a joy to key conversion program that polls for button presses at a 6 ms interval and converts them to keypresses, I've observed a keypress being detected by the browser 54 ms before the triggering button press in Firefox. 

The additional latency is high enough that the Gamepad API typically provides a much worse experience for games compared to a keyboard or joy to key mapping program.

Can something be done to discourage providing very stale gamepad state when calling getGamepads?

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