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/CAGOLbz2iEGi%3DuFsfNp8u7zBLS6PB6zgsHu21XSqQB4kF%2BcXfQg%40mail.gmail.com.
