Behavior of layers shared between bindings.

[toji]

While reviewing a recent Chrome change I realized there's some clarification needed. Users may be confused by how getSubImage/getViewSubImage handle layers created by other bindings if the other binding was created with a different WebGL context.

Specifically thinking about this scenario:

const gl1 = canvas1.getContext('webgl');
const gl2 = canvas2.getContext('webgl');

// Create two bindings with two different WebGL contexts
const binding1 = new XRWebGLBinding(session, gl1);
const binding2 = new XRWebGLBinding(session, gl2);

// Create a layer with the first binding
const layer = binding1.createQuadLayer({/*...*/});

// Get a SubImage for the layer from the second binding (and thus a different WebGL context)
const subImage = binding2.getSubImage(layer, frame);

// Wait, does this work??
gl2.bindTexture(gl2.TEXTURE_2D, subImage.colorTexture); 

My reading of the spec is that it would fail, because the spec populates the returned XRWebGLSubImage object's textures with one of the textures from a "swap chain" created during the create*Layer() call, using the first binding's context. That feels pretty weird in this case, though, as I specifically asked for a sub image from a binding associated with the second WebGL context.

Now, granted, in my opinion if you are writing the code above you're doing something bad and you should feel bad. BUT, that doesn't stop it from being something that the spec technically allows with potentially counter-intuitive results.

I would argue we should clarify this in one of following ways, given in my personal order of preference:

1. Make calling getSubImage() on a binding other than the one that created the layer an error.
2. Make calling getSubImage() on a binding created with a different context an error.
3. Leave it as is and add a scary non-normative note to the spec explaining more plainly what happens in this scenario with a sad face emoji and a heartfelt "please don't do this".

Thoughts?

(Also, FWIW: Mixing WebGL contexts has been discussed before in #130, but that was only concerned with what happens when the renderState contains layers created by different WebGL contexts, which is a little bit different.)

[cabanier]

Maybe we should limit it even more and throw as soon as you try to create the second XRWebGLBinding. I can't think of a scenario where you would want more than 1

[toji]

I can imagine some tooling scenarios where a utility wants to create and maintain it's own layers internally where it could be useful. I don't see any scenario in which having the ability to retrieve sub images from a different binding than the one that created the layer is beneficial.

[alcooper91]

XRWebGLBinding is also the entry point for raw camera access, depth sensing, and the lighting reflection map; all things that I could imagine being handed off with some kind of abstraction and it being okay to just create it's own.