Why is VRDisplay marked Send and Sync?

[asajeffrey]

I understand why the VRService has to be Send and Sync, because it may be created on a different thread than its used (e.g. created on the main thread, used on the WebVR thread). I don't understand why a VRDisplay has to be. Why not query the VRService for its displays on one thread and then just leave it on that thread?

[MortimerGoro]

It's just because at the time this was implemented we couldn't have all the VRDisplay internal code on the same thread as the VRService. The root of the problem is that Servo used shared OpenGL contexts to share WebGL textures instead of using texture primitives that could be shared among different threads/processes without requiring a shared GL context (e.g. SurfaceTextures on Andriod, IOSurface on Mac, etc)

I'm looking forward to having the VRDisplays fixed to the thread used for the VRService initialization or query. We can remove the Send and Sync once we get the new Servo WebGL texture sharing implemented. We can make the WebXR thread the owner of the VRDisplays and simplify some parts of the code.

[asajeffrey]

OK, so this is just a temporary state of affairs. Yay.