Intent to Ship: XRWebGLBinding interface

[Alex Cooper]

Contact emails

alco...@chromium.org

Explainer

None

Specification

https://immersive-web.github.io/layers/#XRWebGLBindingtype

API spec

Yes

Summary

Exposes a base interface, XRWebGLBinding, introduced by the WebXr Layers spec, and consumed by various other WebXr APIs. Most notably, lighting estimation and raw camera access. This interface would be a stub, exposing only a constructor and no additional methods.

Blink component

Blink>WebXR

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

The Layers spec is generally positively received among other members of the immersive web working group (including the other chromium-based browsers). The biggest risk is that we ship this interface, but then do not ship the other APIs that depend on it. However, at least two of these APIs will soon be under Origin Trials (Raw Camera Access and Lighting Estimation); both of which have strong developer interest; so that risk seems very low. Even if that did come to pass, the maintenance burden of the empty interface should be trivial. A side benefit is that it would avoid websites attempting to feature detect the Layers feature via the presence of this API.

Gecko: No signal

WebKit: No signal

Web developers: Positive Interest in consuming APIs dependent on this interface

Ergonomics

Though implemented in the WebXR Layers API, it is integral in both the WebXR Lighting Estimation and WebXR Raw Camera Access APIs, which we hope to send to Origin Trial soon. There may be other WebXR APIs in the future that depend on or extend this interface as well.

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

Yes

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

N/A, there is no feature to be tested.

Sample links

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/lighting-estimation.html

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/camera-access-barebones.html

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5231377798660096

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Mon, Nov 9, 2020 at 10:53 PM Alex Cooper <alco...@chromium.org> wrote:

Contact emails

alco...@chromium.org

Explainer

None

Specification

https://immersive-web.github.io/layers/#XRWebGLBindingtype

API spec

Yes

Summary

Exposes a base interface, XRWebGLBinding, introduced by the WebXr Layers spec, and consumed by various other WebXr APIs. Most notably, lighting estimation and raw camera access. This interface would be a stub, exposing only a constructor and no additional methods.

Blink component

Blink>WebXR

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

The Layers spec is generally positively received among other members of the immersive web working group (including the other chromium-based browsers). The biggest risk is that we ship this interface, but then do not ship the other APIs that depend on it. However, at least two of these APIs will soon be under Origin Trials (Raw Camera Access and Lighting Estimation); both of which have strong developer interest; so that risk seems very low. Even if that did come to pass, the maintenance burden of the empty interface should be trivial. A side benefit is that it would avoid websites attempting to feature detect the Layers feature via the presence of this API.

Can you expand on that latter point? (on feature detection)

False feature detection seems like the main risk from exposing the constructor.

Gecko: No signal

WebKit: No signal

Any signals regarding the dependent APIs?

 

Web developers: Positive Interest in consuming APIs dependent on this interface

Ergonomics

Though implemented in the WebXR Layers API, it is integral in both the WebXR Lighting Estimation and WebXR Raw Camera Access APIs, which we hope to send to Origin Trial soon. There may be other WebXR APIs in the future that depend on or extend this interface as well.

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

Yes

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

N/A, there is no feature to be tested.

Sample links

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/lighting-estimation.html

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/camera-access-barebones.html

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5231377798660096

This intent message was generated by Chrome Platform Status.

--
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/CAGOLbz0555XxSDvs31KiY2WZf4u%2Brd2aOAsxcq_i0WSijt%2BbeA%40mail.gmail.com.

[Alex Cooper]

Thanks for the response Yoav, responses inline.

On Wed, Nov 11, 2020 at 3:09 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Mon, Nov 9, 2020 at 10:53 PM Alex Cooper <alco...@chromium.org> wrote:

Contact emails

alco...@chromium.org

Explainer

None

Specification

https://immersive-web.github.io/layers/#XRWebGLBindingtype

API spec

Yes

Summary

Exposes a base interface, XRWebGLBinding, introduced by the WebXr Layers spec, and consumed by various other WebXr APIs. Most notably, lighting estimation and raw camera access. This interface would be a stub, exposing only a constructor and no additional methods.

Blink component

Blink>WebXR

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

The Layers spec is generally positively received among other members of the immersive web working group (including the other chromium-based browsers). The biggest risk is that we ship this interface, but then do not ship the other APIs that depend on it. However, at least two of these APIs will soon be under Origin Trials (Raw Camera Access and Lighting Estimation); both of which have strong developer interest; so that risk seems very low. Even if that did come to pass, the maintenance burden of the empty interface should be trivial. A side benefit is that it would avoid websites attempting to feature detect the Layers feature via the presence of this API.

Can you expand on that latter point? (on feature detection)

False feature detection seems like the main risk from exposing the constructor.

This interface, while primarily introduced from the WebXR Layers API is used by several other APIs as well, which we do intend to ship. As such, it's presence or absence is not a good indicator of whether or no the Layers API has shipped (the Layers API has other more suitable objects to use as feature indicators). What I meant was that by shipping this early, we can help introduce that concept ("This is a bad choice for Layers feature detection") early, and thus reduce any issues that it may cause.

 

Gecko: No signal

WebKit: No signal

Any signals regarding the dependent APIs?

No signals from WebKit; however, Mozilla helped to write the spec for the Lighting Estimation API before the recent changes over there. There has been significant interest from the working group about Raw Camera Access as well. It's also worth noting that even though they are a chromium fork, the WebXR Layers API has been primarily driven by Facebook/Oculus. As mentioned below, web developers are very interested in the two dependent APIs.

[Chris Harrelson]

Can you ask for official signals?

 

 

 

Web developers: Positive Interest in consuming APIs dependent on this interface

Ergonomics

Though implemented in the WebXR Layers API, it is integral in both the WebXR Lighting Estimation and WebXR Raw Camera Access APIs, which we hope to send to Origin Trial soon. There may be other WebXR APIs in the future that depend on or extend this interface as well.

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

Yes

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

N/A, there is no feature to be tested.

Sample links

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/lighting-estimation.html

https://storage.googleapis.com/chromium-webxr-test/latest.html?target=proposals/camera-access-barebones.html

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5231377798660096

This intent message was generated by Chrome Platform Status.

--
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/CAGOLbz0555XxSDvs31KiY2WZf4u%2Brd2aOAsxcq_i0WSijt%2BbeA%40mail.gmail.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+...@chromium.org.

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

[Chris Harrelson]

You need to have a TAG review as well - unless this was covered by a previous TAG review?

[Alex Cooper]

Hi Chris,

Mozilla has marked the WebXr Device API as a whole to be "Worth Prototyping", the issue for the Layers API (where this stub primarily originates) is still open, but seems to indicate that they consider most WebXR features to fall under the overall WebXr Device API umbrella.

It looks like WebXr Layers does have an open TAG review here: https://github.com/w3ctag/design-reviews/issues/528.

However, as noted this is simply exposing a stub interface defined in the Layers API, because that interface is used by different dependent features that we intend to Origin Trial soon.

Please let me know if you have any additional questions,

Thanks,

Alex

[Chris Harrelson]

On Wed, Nov 11, 2020 at 10:32 AM 'Alex Cooper' via blink-dev <blin...@chromium.org> wrote:

Hi Chris,

Mozilla has marked the WebXr Device API as a whole to be "Worth Prototyping", the issue for the Layers API (where this stub primarily originates) is still open, but seems to indicate that they consider most WebXR features to fall under the overall WebXr Device API umbrella.

How about WebKit?

 

It looks like WebXr Layers does have an open TAG review here: https://github.com/w3ctag/design-reviews/issues/528.

However, as noted this is simply exposing a stub interface defined in the Layers API, because that interface is used by different dependent features that we intend to Origin Trial soon.

Good point. LGTM1 then, modulo question above.

 

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

[Alex Cooper]

Rather than send for signals on this small interface, I have sent for the dependent Lighting Estimation API: https://lists.webkit.org/pipermail/webkit-dev/2020-November/031594.html

Thanks,

Alex Cooper

[Manuel Rego Casasnovas]

On 09/11/2020 22:53, Alex Cooper wrote:
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

>
> N/A, there is no feature to be tested.

At least we can test if the interface is exposed or not, or am I missing
something?

Bye,
Rego

[Yoav Weiss]

I believe that's automatically tested with the webexposed/ tests

 

Bye,
  Rego

--
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/eaa801a1-b665-51cf-85f9-de570f138c27%40igalia.com.

[Yoav Weiss]

LGTM2

That makes sense, thanks! 

[Manuel Rego Casasnovas]

On 12/11/2020 09:32, Yoav Weiss wrote:
> On Thu, Nov 12, 2020 at 8:56 AM Manuel Rego Casasnovas <re...@igalia.com
> <mailto:re...@igalia.com>> wrote:
>
>
>
> On 09/11/2020 22:53, Alex Cooper wrote:
> >
> >         Is this feature fully tested by web-platform-tests
> >       
>  <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
> >
> > N/A, there is no feature to be tested.
>
> At least we can test if the interface is exposed or not, or am I missing
> something?
>
>
> I believe that's automatically tested with the webexposed/ tests

That's in our internal tests, but not in WPT.

I'm fine with this as it seems very small and useful for future origin
trials, but I believe it'd be good to add a basic IDL test in WPT.

LGTM3 with a WPT test.

Bye,
Rego

[Alex Cooper]

Hi Manuel,

Can you elaborate on what kind of WPT test you want here?

Like Yoav said, really the only thing we can test is just the presence of the Interface, and I don't think I really see the value in that?

Thanks,

Alex

[Alex Cooper]

Further,

Would it be okay to merge/ship this stub now, while I work with (it seems like foolip@) on getting the idl tests turned on for the Layers API (which this is the only thing we're shipping from that), and the WebXR Lighting Estimation API (the most stable dependent API); as it looks like that is ~an automated process?

Thanks,

Alex

[Manuel Rego Casasnovas]

Checking the presence of the interface, it's the kind of thing I was
looking for. Then you can easily check which browsers support the
interface, by just checking wpt.fyi for example.

You could write a complete IDL test for the interface, methods and so
on. You'll be failing most of them until some stuff is implemented, and
then some start to pass. That could be an option too.

If you have plans to add tests for this in the short term I guess that's
fine too, and it's not a big deal to ship the interface some time
earlier than landing the related tests. But usually it's good to have
tests in WPT so we ensure interop with other implementations and we can
easily check the status of features on the different browsers.

Bye,
Rego

On 12/11/2020 21:39, Alex Cooper wrote:
> Further,
>
> Would it be okay to merge/ship this stub now, while I work with (it
> seems like foolip@) on getting the idl tests turned on for the Layers
> API (which this is the only thing we're shipping from that), and the
> WebXR Lighting Estimation API (the most stable dependent API); as it
> looks like that is ~an automated process?
>
> Thanks,
> Alex
>
> On Thu, Nov 12, 2020 at 12:31 PM Alex Cooper <alco...@google.com
> <mailto:alco...@google.com>> wrote:
>
> Hi Manuel,
>
> Can you elaborate on what kind of WPT test you want here?
>
> Like Yoav said, really the only thing we can test is just the
> presence of the Interface, and I don't think I really see the value
> in that?
>
> Thanks,
> Alex
>
> On Thu, Nov 12, 2020 at 12:29 PM Manuel Rego Casasnovas
> <re...@igalia.com <mailto:re...@igalia.com>> wrote:
>
>
>
> On 12/11/2020 09:32, Yoav Weiss wrote:
> > On Thu, Nov 12, 2020 at 8:56 AM Manuel Rego Casasnovas
> <re...@igalia.com <mailto:re...@igalia.com>

[Alex Cooper]

Thanks Manuel,

I'm not sure what kind of signal support for this one interface would indicate (we're not supporting most of the methods on it, and we'd have tests for the other APIs dependent on the interface separately).  However, I did a bit of digging after your comment, and there are some requirements stated for construction of the interface (https://immersive-web.github.io/layers/#dom-xrwebglbinding-xrwebglbinding), so I'm going to add a WPT for that before shipping.

Thanks,

Alex