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.)
On 2017-03-01 3:50 PM, kgil...@mozilla.com
> 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.
> 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.
> Kearwood “Kip” Gilbert