Intent to Experiment: WebXR Depth API

[Piotr Bialecki]

Contact emails

bia...@chromium.org, mlam...@chromium.org

Explainer

https://github.com/bialpio/webxr-depth-api/blob/master/explainer.md

Specification

None

Design docs

https://github.com/bialpio/webxr-depth-api/blob/master/explainer.md

Summary

The Depth API allows applications access to depth buffer information that conveys information about the user's environment in Augmented Reality scenarios.

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/550

TAG review status

Pending

Risks

Interoperability and Compatibility

The feature is in Immersive Web CG to kick off discussions about interoperability and the API design. The design itself took into account ARCore (Android) and ARKit (iOS, marked as Beta) APIs to present an API shape that could be implemented in both of those platforms, and tried to ensure that other platforms that offer higher-level APIs (world reconstruction) could implement it as well.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Ergonomics

This feature is an extension of WebXR Device API. The use of this particular feature does not depend on any other web features, although WebXR-enabled applications will most likely use WebGL.

Activation

The feature is usable as-is, although it will be more accessible to developers if used through libraries like three.js, <model-viewer>, A-Frame, etc.

Goals for experimentation

The main goal of the experiment is to gather feedback on the API shape / ergonomics from the developers - the API offers a way to access depth data on the CPU - depending on the developers' needs, there is a possibility for the API to prioritize GPU access.

Reason this experiment is being extended

N/A.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

No

This will be supported on platforms where Chrome supports AR. Currently, this is only Android. There are no technical restrictions specific to this API preventing it from being implemented on other platforms. The specification itself will be implemented in Blink for all platforms, but the spec text leaves room for the UAs to signal that a particular API depends on the device support.

Is this feature fully tested by web-platform-tests?

No

Tracking bug

https://crbug.com/1119487

Launch bug

https://crbug.com/1131625

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5742647199137792

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/U5Iy4LrcwoI/dIlbC2OhAwAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

What's the experimental timeline? Do you have partners lined up to experiment and provide feedback?

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28396c7d-f23d-4fc4-8ee2-2ccbb96d16c4o%40chromium.org.

[Mounir Lamouri]

Hi Yoav,

The experiment would run for two releases. We do not have a strong partner lined up, which is a key reason why we want to run this origin trial. There is a very active XR community that has been using a lot of APIs we've been implementing behind a flag. All the previous XR APIs we launched (and some coming) were required or strongly recommended for all XR experiences so they had obvious integrations in popular libraries such as three.js, model-viewer, or aframe but this one is an advanced feature and we would like to see what the community does with it and hear their feedback before launching it.

Thanks,

-- Mounir

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiwGqkZpHKjAHJezci7scyeeGOMGOmVE3i5Mw1R4pHRLQ%40mail.gmail.com.

[Yoav Weiss]

Do you have any community members that have expressed interest and intend to try the feature out? I'm concerned about a situation where the OT would run and end before any meaningful feedback would be collected, which is not uncommon in OTs that don't have partners lined up ahead of time.

[Mounir Lamouri]

The feature itself is available in both ARCore (Android) and ARKit (iOS) and is used by the native AR viewers on the respective platforms so we are not quite worried about the feature itself being useful. However, the working group has been going through a lot of changes recently and we are not sure we would get a lot of feedback on the API shape at the moment. We could attempt to launch in the next release but it feels that delaying a bit while allowing web developers to experiment with it is a better option. The XR community has been very active and I would expect a few authors to try out this feature and that would be better than having them try it out by asking users to turn on a flag. We do not expect strong feedback on the API shape from web developers as it is a simple addition to WebXR (one new method returning an object).

In short, by running an origin trial, we allow web developers to experiment with an API that we think is ready while allowing the working group to give us more feedback. By not launching now, we commit ourselves to update the API if the feedback comes before the end of the OT.

Thanks,

-- Mounir

[Yoav Weiss]

That makes sense. LGTM to experiment.

Just to clarify, we're talking about experimenting in M87-88?

[Mounir Lamouri]

That's correct, assuming that we can still catch the M87 train. I believe it should be the case.

-- Mounir