I'm not entirely convinced that sharing the GL thread would be the right approach here.

However, this would be relatively simple if we went with my previous suggestion of having a provider per session type, so we can easily spin up both a VR presentation provider, and an AR provider, and just bind the AR provider to GVR's GL thread rather than the AR-specific GL thread. Unless I missed a bunch of discussion, there's still a lot we'd have to figure out... like will rendering work similarly to AR magic window? Do we pre-populate the submitted frame with stereo camera data and run the page's GL on top?

Assigning to mthiesse to determine whether this is a good idea. Note that we are refactoring the device code ( issue 842025 ).

I think sharing GL threads would be a bad idea. Both ArCore->Update() and GVR's swap_chain_.AcquireFrame() block. Trying to do any sort of scheduling using these two APIs on the same thread would probably be a total nightmare.

Also hopefully devices that can take advantage of GVR and ArCore simultaneously are powerful enough to have multi-threaded processors and we should take advantage of that.