WebVR

[torgo]

http://webvr.info also new community group...

[triblondon]

@slightlyoff can you send me your points, and I'll integrate those I already have.

[meganlindsay]

@toji, @slightlyoff

We're requesting a TAG review of WebVR and the related gamepad API extensions for VR controller support. Possibly to get us on the schedule the week of 8/22?

Explainer doc will be ready shortly, proposed APIs are here:

WebVR: https://w3c.github.io/webvr/

Gamepad extensions:
w3c/gamepad#25
w3c/gamepad#26

[torgo]

Picked up 31-Aug-2016. We're working to get you a review.

[meganlindsay]

@torgo

We are intending to ship in Chrome 55, would appreciate it if we could expedite the TAG review scheduling to the week of Sept 12 or 19.

[travisleithead]

I'm planning on working on this the week starting Oct. 3 (have TPAC next week, then home remodeling the week after). If Alex can make progress faster, then perhaps the week of the 26th is possible...

[bfgeek]

One thing that would be good to get early feedback on from the TAG is this specific issue:
immersive-web/webxr#128

[travisleithead]

Taken up at our Tokyo face-to-face meeting.

Re: immersive-web/webxr#128, we tend to agree that the pattern is not very "webby". As noted, the same amount of mem-copying is used in both approaches, but in the "new object" approach, you must additionally allocate a new var (at a minimum), and that's what I understand the concern to be (GC backpressure). @slightlyoff and I agree that it's a bit premature to be concerned about how much of a real-world problem this is without concrete implementation data, and so lacking that, we would be in favor of changing to a model that returns a new object instance each time.

As an alternative approach, the frame data could be considered a mutable state object, and you would use a singleton to store all the data (and to freshen the frame data within), and announce changes via events:

partial interface VRDisplay {
   readonly attribute VRFrameData currentFrameData;
};

where the VRFrameData object has a change event. In this way you avoid allocated new objects each frame in a way that is more "webby". This is not prescriptive, just an alternate approach.

For the larger review, I haven't yet started it, but in discussion at our meeting, one concern raised was how much work would be required on the UI thread to achieve a 120Hz framerate, and whether it makes sense to require off-thread processing via off-screen Canvas.

[slightlyoff]

Thanks to @bfgeek for his help in putting together a draft review: https://github.com/w3ctag/spec-reviews/blob/master/2016/11/webvr.md

/cc @toji @bfgeek @travisleithead @meganlindsay

[cynthia]

Brought up in Tokyo F2F.

We took a second look at this. It seems like the focus of the work has been shifted to 2.0 (whereas our review above was on 1.x) which presumably is in heavy development. We would be extremely interested in having a architectural decisions (and figure out dependencies and upstreaming work to dependent platform specs) - would the group be interested in this?

@toji @RafaelCintron (feel free to add others into the loop)

[cynthia]

We had a discussion whether or not it was a good idea to have a isolated VR world.

[toji]

+@cvan @kearwood @NellWaliczek and @DigiTec, to name a few.

A bit of background: After both the previous TAG review of 1.x and input from several other sources the WebVR community group collectively decided that we needed to make larger, backwards-compatibility-breaking changes to the spec before it was ready for widespread use. We've dubbed this effort "2.0" for disambiguation purposes within the group, but do not intend to promote it publicly as a 2.0 API (it will replace any implementations of the 1.x API and simply be called "WebVR").

Our intention has been to present the revised API for TAG review once we had agreed on the high level approaches we wanted to take for a few outstanding questions so that we could get feedback on all major aspects of the API. We're happy to discuss the current state of things with anyone who has questions, though! In the meantime the WebVR explainer is the best place to review the current designs. (For the record This branch is a bit newer and reflects some more of the ongoing discussion in the GitHub issues.)

On the topic of isolating VR from the rest of the web, the members of the community group all pretty much agree that we want to bridge the gap between the two over time. Our focus for the moment is a minimum viable spec that gives basic access to the hardware, and once that's shipped we can layer on various capabilities to harness more of the traditional web in VR and visa-versa. In the meantime we are putting a pretty heavy emphasis on VR as a progressive enhancement to more traditional WebGL content, rather than encouraging developers to build VR-only pages.

Please feel free to reach out with questions at any time!

[cynthia]

Now that we have #185, maybe we should close this and move the discussion there?