Intent to Ship: WebXR Layers

[Chromestatus]

Contact emails

alco...@chromium.org, baj...@chromium.org, eale...@google.com, yyon...@google.com

Explainer

https://github.com/immersive-web/layers/blob/master/explainer.md

Specification

https://www.w3.org/TR/webxrlayers-1

Summary

WebXR Layers offers a more efficient way of drawing immersive content. In addition to support for native color and depth textures and texture arrays, it also provides support for different layer types that are managed by the system compositor (as opposed to javascript).

Blink component

Blink>WebXR

Web Feature ID

webxr-layers

Motivation

Performance: Layers are presented at the frame rate of the compositor but can be updated at a lower rate in the browser. The compositor can reproject layers at high refresh while the browser just needs to draw pixels when they need to change (instead of when the user moves) Legibility / visual fidelity: In a typical WebXR session, the pixels are resampled twice. This greatly affects text legibility by drawing into a layers, resampling only happens once. Power consumption / battery life: Because the browser only has to render the pixels that changed and can rely on the compositor to draw cubemaps and equirects, far less javascript and gl commands need to run in the browser which increases the system's battery life. Latency: Since the compositor always has the latest pose data and runs at very high system priority, the scene will “stick” to the right location which improves the experience and lowers user fatigue. A good example where this all comes to gether is 360 videos. With regular WebXR, a large framework and very careful coding is needed to do the reprojection. Typically, the resolution and framerates of the video is lowered so the experience can fit in the cpu/memory budget of the device. The efficiency gains of layers should enable such video to reach parity quality with what is possible in native apps on XR devices. Additionally it significantly reduces the amount of

Initial public proposal

https://github.com/immersive-web/proposals/issues/46

TAG review

https://github.com/w3ctag/design-reviews/issues/528

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

The spec is based upon the feature set of OpenXR with wide consensus/support across devices & operating systems. As long as the platform supports this standard (or something close to it), it should be possible to implement.

Gecko: Defer (https://github.com/mozilla/standards-positions/issues/412)

WebKit: Support (https://github.com/WebKit/standards-positions/issues/601) Safari WG member has no objections to the spec moving from the CG to the WG

Web developers: Positive Positive initial response (privately) from multiple popular XR video framework developers.

Other signals:

Ergonomics

The WebXR layers API is extending the WebXR feature set. Its primary use case is improved performance and rendering quality. Today, authors have to rely on large frameworks to render high quality 360 or 180 video and they have to be very careful to not overload the system. With layers, this is now natively supported by the browser and since the compositor will do a lot of the heavy lifting, the load on the browser is significantly lower. We expect this API to improve developer ergonomics in WebXR.

Activation

Not all user agents will have immediate support for this feature. To mitigate this, we are planning on creating a polyfill.

Security

This spec leans heavily on WebXR existing security mitigations. The spec calls out some additional rules.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

WebXR Layers are debugged in the same fashion as regular WebXR.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
The feature performs best if the platform has native support for layers which can be done through OpenXR or some other native API. We expect that most implementations will take that path. It might be possible to build a compositor into Chrome itself as a fallback.

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/webxr/layers?label=experimental&label=master&aligned

Flag name on about://flags

WebXR Projection Layers

Finch feature name

WebXRLayers

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://buganizer.corp.google.com/issues/409255534

Estimated milestones

Shipping on Android

147

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6634466544058368?gate=5852705186775040

This intent message was generated by Chrome Platform Status.

[Alex Russell]

LGTM1; thank you so much for the detailed Explainer.

Best,

Alex