LGTM3
I am a little bit curious about the cliff hangar: "Additionally it
significantly reduces the amount of"
/Daniel
On 2026-02-06 11:30, Philip Jägenstedt wrote:
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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdgKfmizmsJLqYPjvZ3MBPVgzOkcqU6SN4RuW2g0LZt1Q%40mail.gmail.com?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/12ecf730-59f6-46eb-bfed-f697f1bcfef9%40gmail.com.
