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, kgilb...@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. > > 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 > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
