Intent to Ship: XRWebGLBinding interface

136 views
Skip to first unread message

Alex Cooper

unread,
Nov 9, 2020, 4:54:03 PM11/9/20
to blink-dev

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

unread,
Nov 11, 2020, 6:09:54 AM11/11/20
to Alex Cooper, blink-dev
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

unread,
Nov 11, 2020, 12:52:43 PM11/11/20
to Yoav Weiss, blink-dev
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

unread,
Nov 11, 2020, 1:08:26 PM11/11/20
to Alex Cooper, Yoav Weiss, blink-dev
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.

Chris Harrelson

unread,
Nov 11, 2020, 1:09:36 PM11/11/20
to Alex Cooper, Yoav Weiss, blink-dev
You need to have a TAG review as well - unless this was covered by a previous TAG review?

Alex Cooper

unread,
Nov 11, 2020, 1:33:00 PM11/11/20
to Chris Harrelson, Yoav Weiss, blink-dev
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

unread,
Nov 11, 2020, 1:56:41 PM11/11/20
to Alex Cooper, Yoav Weiss, blink-dev
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.
 

Alex Cooper

unread,
Nov 11, 2020, 2:23:23 PM11/11/20
to Chris Harrelson, Yoav Weiss, blink-dev
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

unread,
Nov 12, 2020, 2:56:55 AM11/12/20
to Alex Cooper, blink-dev


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

unread,
Nov 12, 2020, 3:32:45 AM11/12/20
to Manuel Rego Casasnovas, Alex Cooper, blink-dev
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.

Yoav Weiss

unread,
Nov 12, 2020, 3:36:11 AM11/12/20
to Alex Cooper, blink-dev
LGTM2

That makes sense, thanks! 

Manuel Rego Casasnovas

unread,
Nov 12, 2020, 3:29:48 PM11/12/20
to Yoav Weiss, Alex Cooper, blink-dev


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

unread,
Nov 12, 2020, 3:31:46 PM11/12/20
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev
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

unread,
Nov 12, 2020, 3:39:39 PM11/12/20
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev
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

unread,
Nov 12, 2020, 4:50:52 PM11/12/20
to Alex Cooper, Yoav Weiss, blink-dev

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

unread,
Nov 12, 2020, 5:02:06 PM11/12/20
to Manuel Rego Casasnovas, Yoav Weiss, blink-dev
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
Reply all
Reply to author
Forward
0 new messages