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 <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 >> >> 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 >>> >>> >>> 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 >>> >>> >>> 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/5c0cf62d-7258-4380-ae2f-edc9210fc813n%40chromium.org.
