On some devices, a slow path may be required if the user provides an outputContext?

[asajeffrey]

If a user provides an outputContext in the session creation optionas (https://immersive-web.github.io/webxr/#xrsessioncreationoptions-interface), this will contain an HTMLCanvasElement that was created by the document.

In environments where the XR device has a GL context, and the browser has a GL context, but these do not share GL objects (https://www.khronos.org/opengl/wiki/OpenGL_Object#Object_Sharing) such as textures, the GL context of the HTMLCanvasElement will be the browser's not the XR device's. Such an environment can come about when the browser's screen is using a different GPU from the XR device's display.

As a result, when the user provides an outputContext, the UA has little option but to copy the frame buffer out of the browser's GPU into main memory, and then into the XR device's GPU, for each XR animation frame.

If the user does not provide an outputContext, the UA could create one that uses the XR device's GL context, so WebGL draw commands would be executed directly in the XR device's GL context, without needing to blit via main memory each animation frame.

It would be nice if the spec did not preclude such a fast path, and if there was some way to make clear to users when a slow path is required.

[asajeffrey]

Related: #527

[asajeffrey]

This issue is addressed by https://immersive-web.github.io/webxr/#contextcompatibility