LGTM1; thank you so much for the detailed Explainer. Best,
Alex On Wednesday, February 4, 2026 at 10:17:37 AM UTC-8 Chromestatus wrote: > *Contact emails* > [email protected], [email protected], [email protected], > [email protected] > > *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 > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebXR%22> > > *Web Feature ID* > webxr-layers <https://webstatus.dev/features/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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > 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 > <https://chromestatus.com>. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4885ae9e-4412-4c2b-8e86-7eb2534ca0f6n%40chromium.org.
