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

I would like to see an extension to the spec that allows gamepad data to be requested directly from within web workers.

It is extremely difficult to avoid blocking and stalls in a window's main javascript context. Moving gamepad interactions to a worker avoids blocking related to other events flooding the window context and may reduce stalls related to garbage collection on some browsers.

The two problems that are meant to be solved by this feature are:
1. Allow accurate and reliable timing for all interactions including button, joystick, touchpad, etc.
2. Minimize the risk of missed button presses.

Detecting the timing of a button press and release is extremely difficult to do reliably in the current iteration of this API. If you assume a button is pressed when the gamepad is polled, the timing of a button press has an error equal to the polling rate and the duration of a button press always has an error of 2x the polling rate. For an application running at 30hz and polling gamepads once per frame there is a 33ms error for determining when a button was pressed and a 67ms error for determining the duration of a button press. (Please don't try to convince me that every application always runs at 60hz on every platform.)

Rhythm games (Dance Dance Revolution, Guitar Hero, etc) benefit greatly from having a high update rate input loop decoupled from the game loop, since you can run with low frame rates and still maintain the high accuracy input timing required for the game to function. Fighting games are similarly desperate for accurate timing on their user input. (Do you think the current api can register this command on a joystick reliably: ←→↘↓↙← )

Accurate timing is also dependent on the browser not arbitrarily querying the gamepad at a low rate and providing stale data on repeated calls to getGamepads. The current api does not provide timestamps on gamepad state, which means it is impossible to determine if the data is stale or by how much. If the getGamepads function does not actually get a fresh update from the hardware this also means that using the Gamepad API will usually have strictly worse latency using a gamepad than with a keyboard or mouse. Last I checked, with the implementation of the Gamepad API in Chrome, you get dramatically better timing and latency if you use a joystick to keypress conversion program with a gamepad rather than using it directly in the gamepad API due to buffering API calls.

There are two other possible solutions that solve the same problems but don't seem like they would ever make it into the spec.

1. Provide a polling function that takes a DOMHighResTimeStamp as an argument and returns an array of gamepad states with timestamps that respresent each hardware/driver update from the gamepad that has occured since the provided timestamp. (This will never happen because of complaints that it provides too much data and there will never be an agreement on the polling rate. Also, some input APIs, XInput for example, provide no mechanism to determine the update interval of the controller.)

2. Provide an event driven API or mechanism to poll for events, with events that include a DOMHighResTimeStamp for each event. (This will never happen because of complaints that joystick jitter creates too many meaningless events and a lack of agreement on the details of events. There have been multiple requests for an event API that have stalled even in spite of the fact that Firefox has already partially implemented it.)

-- 
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/37