LGTM2, and I agree the explainer made it immediately clear what this is for.
On Wed, Feb 4, 2026 at 9:37 PM Alex Russell <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4885ae9e-4412-4c2b-8e86-7eb2534ca0f6n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAARdPYdgKfmizmsJLqYPjvZ3MBPVgzOkcqU6SN4RuW2g0LZt1Q%40mail.gmail.com.
