Must UAs support composing 2 projection layers without the "layers" feature descriptor?

[Alex Turner]

The layers spec requires that the page negotiate for the "layers" features descriptor before allowing the page to make quad layers, cylinder layers or equirect layers.

This is presumably for one or both of these reasons:

• This allows a UA on a device that does not support efficient layer composition to avoid encouraging an app pattern that would reduce quality rather than increase it on the device, while still allowing use of texture arrays through the new API.
• This allows a simpler UA built on an XR platform that does not happen to expose layer composition to avoid having to implement its own multi-layer precompositor.

However, as the spec is currently written, an app could make use of 2+ projection layers without declaring the "layers" capability:

If an application wants to create layers other than of type XRProjectionLayer during a session, the session MUST be requested with an appropriate feature descriptor.

This would break both of the motivations above:

• A device that cannot efficiently compose 1 projection layer and 1 quad layer is unlikely to do any better composing 2 projection layers.
• If a simple UA does not wish to implement its own layer composition, it would rely on the underlying XR platform to compose multiple layers. However, I do not know of any native XR APIs that do not support quad layer composition but do support composition of 2 projection layers.

We should tighten up the case where the app does not declare the "layers" feature descriptor to disallow more than 1 layer, regardless of the type of the second layer.

[Rik Cabanier]

We discussed this in the past and we were waiting for responses from UA's that wouldn't be able to create more than 1 projection or webgl layer.
It sounds like you think we should have that limitation as the default. Do you know of any UA's that can only create a single layer?

[Alex Turner]

I know of a few categories of native XR platforms:

• XR platforms that do not support more than one layer at all (e.g. SteamVR and the first HoloLens)
• XR platforms that support some specific subset of "full" layer composition (e.g. WinMR's previous native API: supported 1 projection and 4 quad layers)
• XR platforms that support any number of projection and quad layers up to the overall maximum. (e.g. OpenXR without the cylinder layer or equirect layer supported)
• XR platforms that support any number of projection, quad, cylinder and equirect layers up to the overall maximum. (e.g. OpenXR with the cylinder layer and equirect layer supported, or Oculus' previous native API)

Here is the current state of the WebXR spec:

• If you do enable the "layers" feature, you can make any number of projection, quad, cylinder and equirect layers, up to the overall maximum. (matches OpenXR and Oculus' previous native API)
• If you do not enable the "layers" feature, you can make 2 projection layers, but not 1 projection and 1 quad layer. (does not match any known native XR API)

The behavior when you do enable the "layers" feature is consistent with known native XR platforms. I do not know of any platforms that map to the behavior when the "layers" feature is disabled.

I believe it would be cleaner to update the WebXR spec to the following:

• If you do enable the "layers" feature, you can make any number of projection, quad, cylinder and equirect layers, up to the overall maximum. (matches OpenXR and Oculus' previous native API)
• If you do not enable the "layers" feature, you can make 1 projection layer. (matches SteamVR and the first HoloLens)

[Rik Cabanier]

That sounds reasonable to me. I will make that change.

[Rik Cabanier]

@thetuvix I created #206
Do you think I should disallow creating more than 1 projection layer? We currently don't stop UA's from creating more than 1 WebGL layer so it's a bit weird to put that limitation in for projection layers.
The spec also become a bit weird to deal with having only one layer.