Thanks for answering all these questions, Alexander. LGTM1
On Monday, June 2, 2025 at 10:56:59 AM UTC-7 Alexander Cooper wrote:
Thanks Mike. I believe I've made all of the changes requested.
> Can you update the chromestatus entry with this info (see the
"Platform Support Explanation" field)? Thanks.
Done.
> I'm responding to the "Debuggability: None" in your email and
chromestatus entry. It sounds like that should be updated to
something like "no special needs" or "existing tools cover debugging".
I believe I've now added a note to the appropriate space on the
chromestatus entry.
> Thanks, that's helpful for non-WebXR experts. Which of the 3
were already implemented by Meta?
If I understand correctly the "matchDepthView" and corresponding
implementation of XRViewGeometry (transform/projectionMatrix
attributes) were implemented by them, or are at least fairly
close. I'm not sure if they've done the pause/resume methods yet,
but they provided feedback to the shape wrt their runtime. I do
think it is unlikely they will implement raw/smooth anytime soon
due to the nature of their runtime, but that particular feature is
the one that IMO has the least flexibility in naming of the three.
+Rik Cabanier <mailto:caban...@gmail.com> (of Meta who has
commented on WebXR launches in the past) in case he can add any
additional context here.
On Mon, Jun 2, 2025 at 5:16 AM Mike Taylor
<miketa...@chromium.org> wrote:
On 5/30/25 12:47 PM, Alex Cooper wrote:
> Can you say more why you think a TAG review isn't
applicable here? I see that TAG has reviewed a number of
WebXR features in the past:
https://github.com/search?q=repo%3Aw3ctag%2Fdesign-reviews+webxr&type=issues
<https://github.com/search?q=repo%3Aw3ctag%2Fdesign-reviews+webxr&type=issues>
They have. By and large this is collectively 3 small updates
to an existing API that either follows the established
patterns of the API and/or are small enough features that
can't really be done in another way. Furthermore, there was
already fairly substantial cross-vendor iteration on this.
Finally, it is my understanding that several of these items
have also already been implemented in the Meta Quest browser.
Thanks, that's helpful for non-WebXR experts. Which of the 3
were already implemented by Meta?
> Could we file a position request at
https://github.com/WebKit/standards-positions/
<https://github.com/WebKit/standards-positions/>, and let
them know we're proposing to ship this? Or maybe it makes
more sense to add a comment to
https://github.com/WebKit/standards-positions/issues/155
<https://github.com/WebKit/standards-positions/issues/155> -
I'll leave that up to you.
We've typically been filing new issues. For what it's worth,
the bulk of the Depth API *is* shipped. This particular
chromestatus is about the three incremental features to allow
for improved performance knobs to be exposed to developers. I
went ahead and filed the issue for the overall API here
though:
https://github.com/WebKit/standards-positions/issues/503
<https://github.com/WebKit/standards-positions/issues/503>
Thank you. And by "this" I'm referring the 3 updates you're
proposing to ship.
> I would assume remote debugging with DevTools works here,
is that correct?
I'm not sure what you mean? You can access all of the methods
etc. via the DevTools as with any API. We didn't do anything
special to enable debugging scenarios, but also nothing that
would block default tooling from working.
I'm responding to the "Debuggability: None" in your email and
chromestatus entry. It sounds like that should be updated to
something like "no special needs" or "existing tools cover
debugging".
> Can you say more? I'm guessing just Android, but would be
good to confirm.
Technically OpenXR (one of the WebXR backends) *does* run on
Windows; but I know of no runtimes that expose the extensions
we'd need there. So while technically the features are
supported on Windows and Android, functionally they will only
work on Android.
Can you update the chromestatus entry with this info (see the
"Platform Support Explanation" field)? Thanks.
On Fri, May 30, 2025 at 6:30 AM Mike Taylor
<miketa...@chromium.org> wrote:
On 5/22/25 1:45 PM, Chromestatus wrote:
Contact emails
alcoo...@chromium.org
Explainer
https://github.com/immersive-web/depth-sensing/blob/main/explainer.md
<https://github.com/immersive-web/depth-sensing/blob/main/explainer.md>
Specification
https://immersive-web.github.io/depth-sensing
<https://immersive-web.github.io/depth-sensing>
Design docs
https://docs.google.com/document/d/1Nx3hCHqq8UZ6E1nxctmkr6BBQKwf3AgIai7WVsQ_nUM/edit?usp=sharing
<https://docs.google.com/document/d/1Nx3hCHqq8UZ6E1nxctmkr6BBQKwf3AgIai7WVsQ_nUM/edit?usp=sharing>
Summary
Exposes several new mechanisms to customize the behavior
of the depth sensing feature within a WebXR session,
with the goal of improving the performance of the
generation or consumption of the depth buffer. The key
mechanisms exposed are: the ability to request the raw
or smooth depth buffer, the ability to request that the
runtime stop or resume providing the depth buffer, and
the ability to expose a depth buffer that does not align
with the user's view exactly, so that the user agent
does not need to perform unnecessary re-projections
every frame.
Blink component
Blink>WebXR
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebXR%22>
TAG review
Cumulatively there are three changes represented by this
feature. All of which are small, cannot really feasibly
be done in a different way and went through multiple
rounds of cross-vendor discussion in the Immersive Web
Working Group. Several of them have already been
implemented by Meta, who have begun updating several of
the well-known libraries (e.g. THREE.js) to consume this
new API shape. Great care was taken to ensure that
existing users of the API can also continue to use the
API as it was originally launched with zero impact from
these new features. They purely provide additive
performance improvements to the pages.
TAG review status
Not applicable
Can you say more why you think a TAG review isn't
applicable here? I see that TAG has reviewed a number of
WebXR features in the past:
https://github.com/search?q=repo%3Aw3ctag%2Fdesign-reviews+webxr&type=issues
<https://github.com/search?q=repo%3Aw3ctag%2Fdesign-reviews+webxr&type=issues>
Risks
Interoperability and Compatibility
These features have been designed to work in a backwards
compatible way. Sites have to explicitly opt-in to
receive any of this new behavior.
/Gecko/: Defer
(https://github.com/mozilla/standards-positions/issues/487
<https://github.com/mozilla/standards-positions/issues/487>)
/WebKit/: No signal
(https://lists.webkit.org/pipermail/webkit-dev/2021-February/031695.html
<https://lists.webkit.org/pipermail/webkit-dev/2021-February/031695.html>)
Could we file a position request at
https://github.com/WebKit/standards-positions/
<https://github.com/WebKit/standards-positions/>, and let
them know we're proposing to ship this? Or maybe it makes
more sense to add a comment to
https://github.com/WebKit/standards-positions/issues/155
<https://github.com/WebKit/standards-positions/issues/155>
- I'll leave that up to you.
/Web developers/: Strongly positive Many of these
changes have been asked for by other developers
/Other signals/: Feature changes were developed in
collaboration with Meta in the Immersive Web Working
Group to address their needs as well.
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?
None
Debuggability
None
I would assume remote debugging with DevTools works here,
is that correct?
Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS,
Android, and Android WebView)?
No
Can you say more? I'm guessing just Android, but would be
good to confirm.
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/depth-sensing?label=experimental&label=master&aligned
<https://wpt.fyi/results/webxr/depth-sensing?label=experimental&label=master&aligned>
Flag name on about://flags
webxr-depth-performance
Finch feature name
WebXRDepthPerformance
Rollout plan
Will ship enabled for all users
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/410607163
<https://bugs.chromium.org/410607163>
Availability expectation
Due to hardware restrictions certain features may only
be available on Chrome for the Forseeable future, but
the rest are either already implemented or should be
implemented relatively soon by Meta.
Adoption expectation
THREE.js has already received updates for some of these
features, and I have had developers explicitly ask for
the rest of the features.
Sample links
https://immersive-web.github.io/webxr-samples/layers-samples/proj-multiview-occlusion.html
<https://immersive-web.github.io/webxr-samples/layers-samples/proj-multiview-occlusion.html>
https://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth-gpu.html
<https://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth-gpu.html>
https://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth.html
<https://immersive-web.github.io/webxr-samples/proposals/phone-ar-depth.html>
Estimated milestones
Shipping on Android 139
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).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5074096916004864?gate=5204438167584768
<https://chromestatus.com/feature/5074096916004864?gate=5204438167584768>
Links to previous Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67fd96b4.170a0220.424d3.03b0.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67fd96b4.170a0220.424d3.03b0.GAE%40google.com>
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
blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/682f62bb.2b0a0220.33c819.044e.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/682f62bb.2b0a0220.33c819.044e.GAE%40google.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
blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc901a29-3eac-4fb1-9ce7-b88debf5f828%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc901a29-3eac-4fb1-9ce7-b88debf5f828%40chromium.org?utm_medium=email&utm_source=footer>.
