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/, 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 - 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
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



            Specification

    https://immersive-web.github.io/depth-sensing


            Design docs


    
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)

    /WebKit/: No signal
    (https://lists.webkit.org/pipermail/webkit-dev/2021-February/031695.html)

    Could we file a position request at
    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 - 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


            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/proposals/phone-ar-depth-gpu.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



            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



    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.
    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.
    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>.


--
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.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44dc7f69-ffe0-46b8-b64d-fe4ae0009951%40chromium.org.

Reply via email to