LGTM3 On Mon, Jun 2, 2025 at 11:25 PM Mike Taylor <miketa...@chromium.org> wrote:
> +1 - thanks Alex and Rik. > > LGTM2 > On 6/2/25 2:20 PM, Alex Russell wrote: > > 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/cdefd569-9e6f-4160-abb7-c94144e8668e%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cdefd569-9e6f-4160-abb7-c94144e8668e%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/CAOMQ%2Bw9C%2BChATECyg%3DLfvrTmFsgPbxiW2V4CSov03tYbKdOwwg%40mail.gmail.com.
