Re: [w3ctag/design-reviews] Review request for WebVR (#185)

Taken up at the London F2F.

We were able to get half-way through reviewing the explainer (to the "mirroring" section).

To that point, we're happy with the explainer; very well written! So far, the framework of the WebVR API looks good to us (though we have some general feedback below that could impact that).

In general we have a couple of high-level concerns that don't seem to be described in the explainer so far--we suspect that the Web VR group may have plans/thoughts about these, but that they're just not written down yet.

The primary concerns are related to 1) isolation, and 2) peak performance.

## Isolation ##

One of the two primary use cases described in the explainer is the "VR Enhanced" scenario. In these cases, we are worried that the embedded nature of Web VR will be result in a potentially poor VR experience because the VR render loop will be competing will all the other content being hosted on the page (which will undoubtedly include tens of ads in iframes--bringing the experience to a crawl :( ). In this respect, we think one of the high-order concerns should be isolation--isolating the Web VR experience in a way that UAs can easily de-prioritize non-VR content while the VR session is active. One way to cleanly create this isolation  today is to use iframes. Iframe integration could be as loose as suggesting it as a best-practice, or as tight as a fundamental requirement to enabling VR. We don't have a concrete suggestion on how to enable the latter, but posit the idea for the group to consider.

## Peak Performance ##

Regardless of the question of isolation, making the WebVR experience run as smoothly and "jank-free" as possible is critical--this is the concern of enabling peak performance. We notice that `OffscreenCanvas` is mentioned once in the explainer. We expect that developers will want to use Workers as a way to offload some rendering logic from the main thread. We were hoping to see more about how this scenario might work in the explainer. We note that Web VR interfaces only seem to be exposed in the main thread. Should they be exposed in a Worker? This would enable the `vrSession.requestFrame` to drive a render loop in a Worker, which is cool. If not, then Alex asks "where's my RAF?" :) 

The "where's my RAF?" question is rather important; in general, this appears to be a missing feature from Workers that is critical to synchronizing rendering with OffscreenCanvas and the main thread. While not technically a requirement of WebVR, we do see WebVR having a big interest in ensuring that such a RAF in a worker would be able to run at the refresh rate required by a VR device. Related to the above paragraph, if the VR experience can be isolated into an Iframe, it might be more tenable to "upgrade" RAF for the entire frame (and it's workers) in a synchronized way (than provide some other coordination mechanism).

In addition, using a Worker adds lots of complexity to the question of how to get other main-thread things like user-input and audio (for the game-like scenario). As new input devices are considered, it would be good to think about how that input could be delivered into a Worker environment.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/185#issuecomment-318386542