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

Regarding the vibration portion of the API, I'm still not sure how much
control we should provide. Don't want to get too closely tied to any
specific native implementation. To that end I've put together a brief
document comparing the APIs that I'm aware of:
https://docs.google.com/document/d/1Ms4RFTI8bz1dTtympPmkb81FLhPdls7n-mfwQoAeyAI/edit?usp=sharing

Comments are welcome, especially if there's a Gamepad API that I've missed.

On Mon, Apr 25, 2016 at 9:03 AM Brandon Jones <bajones@google.com> wrote:

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