WebXR Layers API

[MortimerGoro]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebXR Layers API
• Specification or proposal URL: https://immersive-web.github.io/layers/
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1652709
• Mozillians who can provide input (optional): @kearwood, @daoshengmu, @Manishearth @larsbergstrom, @thomasmo, @jdashg, @bluemarvin, @fernandojsg, @philip-lamb, @asajeffrey

Other information

The spec adds support for composition layers to the WebXR spec. Composition layers have many benefits:

• Improved Performance and judder.
• Better Legibility/visual fidelity for elements such as text, UI, video, quads, cubemaps.
• Reduced Latency and Power consumption

WebXR Layers, specifically XRProjectionLayer, will also enable a better render path for our gecko WebXR implementation:

• Proper way to implement WebXR msaa. We disabled msaa in the current WebXR implementation because the OpaqueFBO approach exposed in WebXR API is not totally compatible with the path forward from the WebGL team. This is causing Firefox to have worse VR quality than other browsers. We need the XRProjectionLayer render path to enable msaa for the users.
• Proper way to enable multiview. Multiview is exposed in WebGL but it requires several copies and conversions from textures to side-by-side FBO in the render path to be connected to WebXR. By using the texture-arrays approach provided in the XRProjectionLayer we can implement multiview with less surface blits and conversions, which are specially slow on mobile. This will help with to improve the WebXR performance.

Regarding privacy or fingerprinting I think it's a pretty safe API. I don't think it exposes anything new that is not already exposed in WebXR and WebGL. The only thing I see is knowing if a device supports compositor layers or not. Our initial plan is to implement the XRPRojectionLayer subset, which is always guaranteed to be supported, so not a problem for that use case. For the other layers, if we consider detecting the layers feature a problem, we could always mark them as supported and just fallback to geometry, reusing the code we already have in the external browser apps (Note: We wouldn't need to add that fallback geometry code to WebXR/WebGL in Gecko. It would be just responsible for sharing the layer info on the SubmitFrame calls, not creating the final fallback geometry).

Tag Review thread

[Manishearth]

cc @asajeffrey

[asajeffrey]

We're in the process of implementing this for Servo. A benefit I'd add is that it makes it more likely that an webxr implementation can avoid a blit when displaying webvr content on the device.

[annevk]

(See also #218.)