Replace base_layer with array<XRLayer>

[Artyom17]

Last TPAC (2018) I've demonstrated a proof-of-concept demo of multi-layer WebXR experience and I think the demo was pretty self-proving: we need support of multiple layers of different types: eye buffers, equirect, cube map, cylinder, etc. That also will allow us to implement HTML-to-layer (or DOM-to-layer) (in opposition to never-going-to-happen HTML-to-texture). While I understand we all are trying to minimize amount of new features in order to ship WebXR v1.0 ASAP, I think we might do at least one thing to make WebXR spec extensible: we may introduce an array of XRLayer s instead of a single 'base_layer' member. I am not even talking about defining all possible varieties of layers yet, we can define them later. Just replace the base_layer with the array. And introduce a max_layers_supported value in XRSession (?) which will be 1 for the most of the browsers. Thoughts?

[NellWaliczek]

Hey Artem, I'm currently working on the hit-test and anchors proposals, but once I've wrapped that up, this is the very next topic on my to-list. Any chance you'd be willing to wait a week or two to kick off this conversation?

[Artyom17]

Thanks, Nell! Absolutely!

[avaer]

I'd like to be part of the convos here; we've been privately using a layers array for quite a while.

Also +1 for defining actual layer types later, while having the array in place for now. That would allow for relatively forward-compatible experimentation without really impacting current implementations that support only a single layer.

[NellWaliczek]

Thanks for your patience!

[kearwood]

IIRC, the original intent was to enable more than one layer by adding something like a "childLayers" array to a layer and assign it to the baseLayer.

IMHO, having an array at the base layer would perhaps be easier to understand. On the other hand, making an array may require us to define things such as the order of compositing earlier. (eg, depth, z-order, or order of array)

Once @NellWaliczek and others are ready to open this one, I'd like to voice my support to land it earlier and be part of the discussion as well.

[Artyom17]

@kearwood If we just have an array of layers then we don't have to worry about their order: it will be natural order of layers in the array. It is more limiting with the idea of childLayers: does this mean that baseLayer is always the first? What if I want to make EquirectLayer the first and the actual WebGLLayer should be rendered on top of it? Should I assign the EquirectLayer to the baseLayer for that and put the actual WebGLLayer into the childLayers? It complicates things, in my opinion.

[Artyom17]

Hey @NellWaliczek , any progress on this?

[NellWaliczek]

@Artyom17 and I met today to discuss and as a result, I've moved this issue from WebXR to the proposals repo. Our plan is to write up the following:

1. A document summarizing the features/differences of layers on a number of different platforms to ensure we have a solid baseline against which to start designing in this area.
2. API design options for supporting multiple layers
3. Requirements and a proposed shape for a Quad/Cylinder layer backed by a texture including the expected behavior on UAs built upon platforms without native support.
4. Requirements and a proposed extending the Quad/Cylinder layer to be backed by DOM content

@TrevorFSmith can we get a "layers" repo opened to do this work?

[TrevorFSmith]

@NellWaliczek @Artyom17

I have created a layers feature repo and set Artem as an admin with the understanding that he will coordinate the creation of the initial explainers. I believe that Nell has admin perms on the repo due to her org role.

Thanks for pushing this topic forward and finding the clarity for the path forward!

I will close this issue and all future conversation and work on this topic should occur in the new repo.