| Intent to ship: WebVR on Windows in Release | kgil...@mozilla.com | 3/1/17 12:50 PM | As of March 1, 2017 I intend to turn WebVR on by default on Windows. It has been developed behind the dom.vr.enabled preference and has been enabled by default on Firefox Nightly and Dev Edition since November 2015. Other UAs shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel. Microsoft Edge and Google Chrome are also intending to ship. Google Chrome has enabled WebVR on Android with an Origin Trial.
This feature was previously discussed in this "intent to ship" thread, for non-release builds: https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 We will support Oculus and HTC Vive by default. Oculus is already enabled; HTC Vive support with OpenVR has been developed behind the “dom.vr.openvr.enabled” preference and will be turned on with this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus. The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived. Windows only support for WebVR would be enabled by default in Firefox 54. OSX is not yet supported by current VR headsets. Beta Linux support for HTC Vive has very recently landed, and will be supported by Firefox after the Firefox 54 uplift. Cheers, Kearwood “Kip” Gilbert :kip |
| Re: Intent to ship: WebVR on Windows in Release | Boris Zbarsky | 3/1/17 1:32 PM | On 3/1/17 3:50 PM, kgil...@mozilla.com wrote:So flip the pref on Windows only, right? If there is no VR hardware, is the idea that navigator.getVRDisplays() returns a promise resolving to an empty array? It's a bit worrying to me that this spec is not written down in sufficient detail to be implemented interoperably [1]. How confident are we that what the other browsers are shipping matches what we're shipping? Are there web platform tests? -Boris [1] For example, what does the VRFrameData constructor actually do? The spec doesn't define it at all. Where is the VRPose inside supposed to come from? What values will it contain? I filed https://github.com/w3c/webvr/issues/195 on this, but note that I've spent all of about 5 minutes skimming the spec and ran into this. I have _not_ done a careful read looking for possible interop problems... |
| Re: Intent to ship: WebVR on Windows in Release | Andrew McCreight | 3/1/17 1:49 PM | Last I looked, we didn't have any tests for VRFrameData, FWIW (bug
1317258). I see some now under servo/ but presumably we don't run those. Maybe I'm missing some. It would also be good to make sure our internal fuzzers are fuzzing these APIs to at least catch basic errors. Andrew > _______________________________________________ > dev-platform mailing list > dev-pl...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > |
| Re: Intent to ship: WebVR on Windows in Release | Kip Gilbert | 3/1/17 2:04 PM | Sent from my iPad > On Mar 1, 2017, at 1:32 PM, Boris Zbarsky <bzba...@mit.edu> wrote:Yes, flipping pref on only for Windows. Later, we will be adding support for Linux and Android. OpenVR support for Linux is in Beta -- I would like to see Linux support come next, in Firefox 55. >Exactly. In addition, our implementation waits until either a WebVR API is called or a WebVR event listener is added before polling underlying API's for devices. >We have worked directly with the other WebVR platform implementers to ensure compatibility. We have regularly scheduled video calls and F2F meetings to improve the spec and remove any ambiguity. We have formed a W3C community working group. A growing number of libraries and sites, including A-Frame, three.js, SketchFab, PlayCanvas, and React-VR, already support WebVR and work cross-platform. Automated web platform testing support is landing imminently with Bug 1323328. Other UA vendors have expressed interest in sharing conformance tests, inspired by WebGL's conformance suite. VRFrameData is described as receiving the output of the VRDisplay.getFrameData function: https://w3c.github.io/webvr/archive/prerelease/1.1/#dom-vrdisplay-getframedata Thanks for all your feedback! |
| Re: Intent to ship: WebVR on Windows in Release | Boris Zbarsky | 3/1/17 2:55 PM | On 3/1/17 5:03 PM, Kip Gilbert wrote:OK, but what is the actual state of that compatibility? https://github.com/w3c/webvr/issues/197#issuecomment-283492774 and https://github.com/w3c/webvr/issues/195#issuecomment-283493130 sure sound like at least Brandon is not on board with those parts of the current API, and he's one of the spec editors. That's good. The question that bothers me is how this interacts with the ship schedule. Yes, but that's totally unrelated to my question about what the _constructor_ does.... -Boris |
| Re: Intent to ship: WebVR on Windows in Release | kear...@kearwood.com | 3/2/17 10:52 AM | On Wednesday, March 1, 2017 at 2:55:53 PM UTC-8, Boris Zbarsky wrote:I tend to agree with Brandon on this particular issue >On the spec issue, I am working to make the initial values explicit as you have suggested: https://github.com/w3c/webvr/issues/195 This has not caused any issues with interoperability, as VRFrameData's values are not considered valid until after a call to VRDisplay.getFrameData initializes them and returns true indicating it was successful. Would this issue block release of WebVR in Firefox 54? |
| Re: Intent to ship: WebVR on Windows in Release | L. David Baron | 3/2/17 11:04 AM | On Wednesday 2017-03-01 12:50 -0800, kgil...@mozilla.com wrote:There seems to be some disagreement within the WebVR community about whether 1.1 was intended to be shipped in stable releases of browsers, e.g., in this thread: https://twitter.com/aeliasnet/status/837139143276711936 What's the intent of the WebVR standards community here? And is your intend to support the features in 1.1 forever, or to take them away at some point? -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) |
| Re: Intent to ship: WebVR on Windows in Release | kear...@kearwood.com | 3/2/17 11:23 AM | On Thursday, March 2, 2017 at 11:04:07 AM UTC-8, David Baron wrote:Chris's response to that tweet sums this up. Our first implementation of WebVR 2.0 will be a system add-on exposing the new API, backed by WebVR 1.1. WebVR 1.1 implementations will be around for a long time and have already been shipped by other UA's. It will take some time for 2.0 to be ready to implement as it is still in conception. When the native implementation within Firefox is updated to 2.0, the system add-on will be updated to provide backwards compatibility to the WebVR 1.1 API. At this point, WebVR 1.1 will be deprecated but supported as long as needed. I expect the timeframe to be several years of support for WebVR 1.1 API in production. The vast majority of sites using WebVR are using one of the WebVR polyfills, such as: https://github.com/googlevr/webvr-polyfill This polyfill provides an even higher level abstraction and enables WebVR on platforms without WebVR support, such as phones with a google cardboard holder. Simply updating this polyfill is all that would be needed for sites that are still on the WebVR 1.1 API once eventually deprecated. |
| Re: Intent to ship: WebVR on Windows in Release | Boris Zbarsky | 3/2/17 7:45 PM | On 3/2/17 1:52 PM, kear...@kearwood.com wrote:That's fine. I agree with you and Brandon too. ;) I'm just worried about possible interop problems more than anything else at the moment. To some extent this is a call people more familiar with how this API gets used and what interop issues can arise should make. Note that per https://github.com/w3c/webvr/issues/128#issuecomment-283854007 the behavior of getFrameData is not interoperable between Edge and Firefox: we create new objects hanging off the VRFrameData each time, while they mutate all the existing stuff in-place. This can lead to bugs like code that tries to optimize by grabbing a reference to one of the typed arrays and then calling getFrameData and assuming the array they are referencing is updated (if they test in Edge). Or not updated and represents the previous frame (if they test in Firefox)... Again, I only spent a few minutes looking at this spec. What would be most helpful here is if someone went through it carefully looking for underpecified bits like this, then filed issues as needed and checked what browsers actually do in the underspecified cases. Then we can decide whether whatever behavior differences we find are sufficient that there is high interop risk from shipping. -Boris |
| Re: Intent to ship: WebVR on Windows in Release | Ehsan Akhgari | 3/3/17 6:49 AM | Hi Kearwood,
I and a few other engineers have been studying the performance of Firefox for several weeks now as part of the Quantum Flow project and one of the serious performance issues that we have been finding in various parts of the browser have been synchronous IPC messages sent from the content process to the parent process. We are tracking the overall issue in bug 1331674, and I had seen WebVR sync IPC messages come up in our measurements as being particularly bad but unfortunately I hadn't gotten a chance to file a bug yet because I didn't realize WebVR is close to being shipped, so sorry for the last minute alarm, but what is our performance story for WebVR? We have some telemetry probe that suggest that some of the DOM APIs that we expose can potentially blow away your entire frame budget. For example, PVRManager::Msg_GetSensorState (which, as far as I can tell is how we implement VRDisplay.getFrameData() and VRDisplay.getPose()) is one of the slowest ones. On Nightly, more than 50% of the calls to this synchronous IPC take between 8 to 20ms. This means calling one WebVR API currently can run the risk of blowing away your entire frame budget. I have filed bug 1344216 for this. I don't have any VR hardware myself so I have done no profiling myself, but what is our performance story here? I think the current implementation strategy of sending synchronous messages to the parent process isn't going to be viable long term, and honestly it seems to me that for WebVR specifically it may not even be good enough for a first implementation. Do you have some Gecko Profiler profiles to share, ideally from lower end hardware that can run VR demos so that we can get a sense of what the performance of Gecko on a VR workload looks like? Has there been though of other implementation strategies? (FWIW it has recently became quite clear that sync IPC messages can be *much* worse than sync IO even, we have seen many profiles where sync IPC messages can easily take *seconds*, so even if they show up as super fast on a fast machine when the machine isn't under load, they can essentially take an arbitrary long amount of time in less ideal cases... I myself have certainly been guilty of adding a fair number of sync IPC messages before measuring how bad they are in practice.) Thanks, Ehsan On 2017-03-01 3:50 PM, kgil...@mozilla.com wrote: > As of March 1, 2017 I intend to turn WebVR on by default on Windows. It has been developed behind the dom.vr.enabled preference and has been enabled by default on Firefox Nightly and Dev Edition since November 2015. Other UAs shipping this include Samsung Internet Browser (Gear VR) and Oculus Carmel. Microsoft Edge and Google Chrome are also intending to ship. Google Chrome has enabled WebVR on Android with an Origin Trial. > > Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ > Since the initial implementation, a W3C working group was formed including members from Mozilla, Google, Microsoft, Samsung, and Oculus. The API has stabilized and is frozen at "WebVR 1.1" while its successor "WebVR 2.0" is being conceived. > Windows only support for WebVR would be enabled by default in Firefox 54. OSX is not yet supported by current VR headsets. Beta Linux support for HTC Vive has very recently landed, and will be supported by Firefox after the Firefox 54 uplift. |
| Re: Intent to ship: WebVR on Windows in Release | Ehsan Akhgari | 3/3/17 10:42 AM | On Fri, Mar 3, 2017 at 12:36 PM, <kgil...@mozilla.com> wrote:
> Hi Ehsan! > > I believe all IPC messages can be changed to async except GetSensorState > and SubmitFrame. We cache the results from GetSensorState and re-use it > until the next frame. > Hmm, not sure if I understand correctly. Did you actually mean "except" there? If we can't guarantee to be able to return the result of GetSensorState in the same frame as when it was requested in (which is the case on Nightly right now), caching it for the rest of the frame duration should be the least of our worries... > I would like to do some changes to how IPC in WebVR works... > > First, I'd like to move the parent side of PVRManager to its own thread or > possibly a dedicated process. WebVR can be impacted by busy message > queues. PVRManager is already a top-level protocol and the methods on the > parent side are self contained in preparation for this. > You probably want PBackground for this purpose, although if you're planning to communicate with the background parent actor synchronously that may not end up being good enough either. A separate process sounds overkill, and probably opens the door to solving more problems that you can probably avoid solving (such as dealing with the additional memory usage of a helper process.) > Secondly, we may benefit from using another IPC mechanism for sharing > per-frame state, which is updating at 90hz and broadcasting the same > information to multiple children. A fundamental difference with WebVR is > that children are interested in getting the latest state rather than state > in a serial fashion. A carefully fenced or double buffered structure (like > Chromium's gamepad IPC) may provide the low latency, nom-blocking IPC here. > Is this something we can use shared memory for? Or would the cost of locking access to the shared memory undo the benefits? > For the near-term, I would like to make sure all messages that occur > outside of WebVR presentation Sorry, I'm not familiar with all of the terminology here. Which messages are those, and what parts of WebVR would still use synchronous IPC communication with your suggestion? > (ie GetDisplays) are async first, then work on a different IPC mechanism > and move WebVR's messages into another parent thread / queue.. Would this > make sense? > My first suggestion is to gather some profiles of some WebVR test runs to get a better sense of what the current situation looks like. Still it seems to me that we shouldn't have any sync IPC on the path of the DOM APIs that are exposed to the page. Cheers, Ehsan > Thanks for the feedback! > > Cheers, > - Kip > > > On Mar 3, 2017, at 6:47 AM, Ehsan Akhgari <ehsan....@gmail.com> -- Ehsan |
| Re: Intent to ship: WebVR on Windows in Release | kear...@kearwood.com | 3/6/17 12:03 PM | On Friday, March 3, 2017 at 10:42:43 AM UTC-8, Ehsan Akhgari wrote:For GetSensorState, we are not just concerned with the call completing within one frame, but also the timing within a single frame as the value will change depending on the timing of the call. We optimize for late frame pose prediction updates by delaying this call as late as possible within one frame to get the most accurate prediction of the headset's future pose at the end of the frame. As sync messages have other side-effects, this is a candidate to be switched to a different mechanism (such as shared memory). >The driving need is that the VR messages would not block on any non-webvr messages in the queue. Ideally we won't need a separate process, but if we do, we would start it only when necessary. The underlying VR API's expect this process to persist for the browser's lifespan and to have mutually-exclusive access to input from the headsets. It seems that the GPU process is the best fit afaict. >I would like to explore using shared memory with lockless data structures. Chromium does something similar: https://chromiumconfessions.blogspot.ca/2016/09/chromium-gamepad-api-and-shared-memory.html GetDisplays is the only IPC that would affect non-webvr sites, and is easy to make asynchronous. It is not timing sensitive and the web-facing api returns a promise. GetSensorState and SubmitFrame would need to be synchronous, but could be using a different IPC mechanism. >I have done a lot of profiling with hardware assisted latency testing to measure sub-frame timing of the render loop, including the IPC calls. I'd like to automate this with tests and also get telemetry feedback from the wild. Thanks for all your constructive feedback! Cheers, - Kip |
| Re: Intent to ship: WebVR on Windows in Release | Boris Zbarsky | 3/6/17 12:15 PM | On 3/6/17 3:03 PM, kear...@kearwood.com wrote:In case it matters, the GPU process does not have "persist for the browser lifespan" as a goal. In fact, the whole point of the GPU process is that driver crashes should take down the GPU process but not the browser. We then restart the GPU process as needed. On some hardware/software configurations, this is apparently not a rare occurrence. -Boris |
| Re: Intent to ship: WebVR on Windows in Release | kear...@kearwood.com | 3/6/17 12:31 PM | It would require some work to allow VR to continue after a GPU crash, but perhaps such isolation could be useful eventually and predicate a separate VR process.
|
| Re: Intent to ship: WebVR on Windows in Release | baj...@google.com | 3/8/17 2:13 PM | Hi all! I'm a spec editor for WebVR and implementer on Chrome. Wanted to chime in on a few points.
Boris: Thanks for the spec bugs you've filed and the concern about improving the spec language to ensure consistent implementations between browsers. The type of issues you have brought up are exactly the sort of thing that we were hearing from Google's side as well and a large part of why we're pursuing what we refer to as the "2.0" spec (which is a terrible name given that it's intended to ultimately be the only version of the spec, but that's a different matter.) The 2.0 version of the spec currently exists mostly in explainer form right now (https://github.com/w3c/webvr/blob/master/explainer.md) while we prep for a TAG review. Once that's complete and we've made the appropriate adjustments we'll start working on real spec language. It's my intent to focus on making that version of the spec far more explicit, algorithmic, and attentive to web platform conventions. (I've been frequently referring to https://garykac.github.io/procspec/ and https://w3ctag.github.io/design-principles/ when figuring out what the spec language should look like.) Given that we know that we have a newer/better version of the spec in the pipeline We've been reluctant to personally put much time into fleshing out the 1.1 version. I don't think I'd classify 1.1 as "stabilized" so much as "no longer being invested in". I wouldn't object to updating it with clarifications if necessary, though. I should also point out that on Google's end we are currently making the 1.1 spec available via an Origin Trial, but have no plans on enabling it by default at this time. It's our intent to continue the Origin Trial while the 2.0 spec is finalized, stripping out some deprecated functionality in the meantime to prevent developers from growing dependent on it. Once 2.0 is ready we'll replace our 1.1 implementation entirely, run the Origin Trial for a little longer to gather feedback, and then enable by default. A few other points of clarification, mostly referring to Kip's original post: - We currently have a W3C community group, rather than a full fledged working group. - Oculus has been participating in development of the spec but (somewhat to my surprise) is not yet an official member of the community group. - Samsung is currently shipping an even older version of the API (what we call 1.0). They are working on 1.1 support now, as I understand it. |
| Re: Intent to ship: WebVR on Windows in Release | Kearwood "Kip" Gilbert | 4/13/17 1:24 AM | We believe that we have addressed the remaining issues and we will turn WebVR on by default in Windows, shipping in Firefox 55.
After discussions with the other major browser vendors, we believe that we are all on track to ship a compatible version of the WebVR 1.1 draft specification and have addressed the issues brought up in this thread. Additionally, Microsoft announced yesterday that their implementation (with whom we share Web Platform Tests) has just shipped with the Creators' Update: https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/ <https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/> We and other browser engines have expressed an intent to either support 1.1 via a polyfill of 2.0 or a side by side implementation, depending on what is easier from their engine. If there is very little uptake or we are able to transition users to 2.0, then we may be able to deprecate 1.1 entirely. We plan to have the discussion around that process in the group later next year, around the time when we expect 2.0 to be finalized. Thanks everyone, within and beyond the MozVR team, for making this possible! Cheers, - Kearwood “Kip” Gilbert > https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion <https://groups.google.com/d/topic/mozilla.dev.platform/BeVaHGEgZNA/discussion> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1343368 <https://bugzilla.mozilla.org/show_bug.cgi?id=1343368> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1343374 <https://bugzilla.mozilla.org/show_bug.cgi?id=1343374> > > Link to standard: https://w3c.github.io/webvr/archive/prerelease/1.1/ <https://w3c.github.io/webvr/archive/prerelease/1.1/> |