sounds like you are asking for a lot of objects to be created? I call this function 100 times per second for accuracy. Creating new objects every time mean a lot of garbage. Is there a reason you can't just store the data you need yourself?

Hi markgfx@, that's interesting that you are calling getGamepads at 100 Hz for better accuracy. We are investigating whether we can increase the internal polling rate for gamepad input to 250 Hz, which would allow you to poll even more frequently for improved latency and fewer missed inputs. The relevant changes are in recent Canary builds, see chrome://flags#gamepad-polling-rate. If you are able to test with this flag enabled, could you report back whether you are seeing any performance regression in your app?

I think in the typical case this will not create a lot of objects, but it will likely create more objects than before. We will use double-buffering to reduce the number of buffers that need to be created. The behavior will be:

* Check if the back buffer exists; if not, create it.
* Fetch current gamepad state into the back buffer.
* If the front buffer is empty or if the back buffer differs from the front buffer, swap buffers.
* If the previous front buffer (now back buffer) was ever returned to the page via getGamepads, release our handle to it so it can be GCed. Otherwise, retain it for reuse.

This means that the "typical" case where an app polls getGamepads in the rAF loop will allocate one new buffer in each frame where gamepad state changes. If the user does not interact with any buttons or axes, the gamepad state should be identical and a new buffer will not be allocated. Continuous input at 60 Hz would allocate 60 of these buffers every second, but typically this would only occur while an axis or analog button is being moved.

> Is there a reason you can't just store the data you need yourself?

I'm not sure what you mean by this. The spec defines getGamepads to return a snapshot of the current gamepad state. When the state changes, we shouldn't return stale data and we also shouldn't overwrite old buffers if they are potentially still in use.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b2f9ade9b9a7ebd8eaa5214fcba3dd8a9c8c0b49

commit b2f9ade9b9a7ebd8eaa5214fcba3dd8a9c8c0b49
Author: Matt Reynolds <mattreynolds@google.com>
Date: Wed Aug 15 23:01:19 2018

Improve gamepad-polling-access layout test

Under normal circumstances, gamepad state can only change in
response to certain triggers. By using the gamepadController test
API, the gamepad state may be changed in response to many more
triggers, including gamepad events themselves, which may cause
some events to not be dispatched. This CL modifies the layout test
to only change gamepad state outside of gamepad event listeners.

This CL also removes a hack where the string representation of the
gamepad state was being compared instead of the underlying buffers.
This hack was intended as a workaround for a bug caused by incorrect
buffer reuse behavior. The bug still exists but the test is modified
to test the reuse behavior as intended.

BUG=855760

Change-Id: I75144ae68efa355992d03692e2fd52b2f832281f
Reviewed-on: https://chromium-review.googlesource.com/1173329
Commit-Queue: Matt Reynolds <mattreynolds@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#583428}
[modify] https://crrev.com/b2f9ade9b9a7ebd8eaa5214fcba3dd8a9c8c0b49/third_party/WebKit/LayoutTests/gamepad/gamepad-polling-access.html