Re: [gamepad] New feature proposals: pose, touchpad, vibration

Lots of good feedback! Replies inline.

> Do we want to know the value of the press? Does the API for the Steam
Controller, for example, return the force of the press as a float?
> Likewise, Pointer Events have "pressure"

GamepadButton already has a "value" property, which I think would be
appropriate to use here. Today it's primarily used for things like analog
triggers or pressure sensitive buttons, but I can't see any reason why it
wouldn't work for touchpads as well. Put another way: while plenty of
touchpads have both a touched and a clicked state, I can't think of a
scenario where a touchpad would have a separate concept of "touch force"
and "pressed amount".

> Just as a quick API surface comment, Float32Array? is not a very good way
of representing a vector (or quaternion).
> Web VR seems to have changed from DOMPointReadOnly to Float32Array? for
some reason. Maybe they can explain?

I should probably explain that I'm an author of the WebVR spec who also
happens to be the current primary Gamepad developer on Chrome. :) Of
course, that makes my opinions on cross pollination between the two APIs
very non-neutral, which is why I think it's important to gather feedback
like this. Thanks!

The WebVR API switched from DOMPoint to Float32Arrays for a couple of
reasons, probably the biggest being that the DOMGeometry types still seem
to be in spec limbo. This is especially true of the DOMMatrix type, which
appears to be fairly contentious from reading through the mailing lists. We
were reluctant to continue relying on a spec with an unclear future or
timeline.

A common concern raised when talking about these types is that they may not
be as performant as developers are expecting them to given their "native"
implementations, since the overhead of transitioning in and out of the
Javascript VM may swamp out the perf benefits you would otherwise see.
Counterintuitively, in order to get the best performance it may be best to
do all of your vector and matrix math in Javascript.

To that end, libraries already exist that operate on Float32Arrays directly
for vector/matrix math (http://glmatrix.net). And SIMD JS, which can
improve the performance of these operations up to 4X in some cases, expects
values to be packed into TypedArrays anyway. It was those potential
benefits and the desire to not create another explicit vector and matrix
type to compete against DOMGeometry that lead us to use flat arrays in
WebVR.

> Why are you interested in creating a competing extension to the Gamepad
API, instead of working with the Web VR folks on their interface?

I've already explained my relationship to WebVR, so I'll point out that I
would view this as a complimentary extension, not a competing one. In a
prior iteration of the WebVR spec things were abstracted out in such a way
that you could have exposed 6DoF information about gamepads via WebVR
instead of the Gamepad API. This proved to make using the API very
confusing for developers. Not only would it have been easy to mistake a
tracked gamepad for a headset, it required some awkward references between
APIs to say "this set of pose information is associated with this gamepad
index at this timestamp". And in some cases (Wii remote) it wouldn't be
obvious why you had to route through WebVR at all in order to get what
should be intrinsic properties of the gamepad itself.

I wouldn't be opposed at all to having Pose be a shared interface between
APIs, used by both WebVR and the Gamepad API. I do feel like it's quite a
bit more natural for developers to have each context surface their own pose
values, though.

I know I haven't fully covered everyone's comments so far, but I wanted to
clarify my relationship to the WebVR API and explain some of the logic
behind it's choices. I have some thoughts on the vibration concerns as
well, but I want to gather a bit more reference material before I dive into
that. Thanks for everyone's input thus far!

--Brandon