Handle STOPPING state correctly

[Manishearth]

Tapping the start menu button works now. It does hide the app, but this is how openxr expects you to handle the stopping state.

One thing that doesn't work right now is that when you hit the home button on the start menu, we do not get any events, nor do we get any events when you tap the greyed-out servo window. This puts the session in a state where it's idle but can't be told that it should wake up again. Not quite sure what to do here.

Also, doing this completely inside handle_openxr_events isn't great; because now we can't receive quit events. It might be worth working this into the larger webxr event loop, though that would involve some tricky control flow.

Fixes #76

Progress towards servo/servo#24722, won't fix that issue until we can exit the session when you tap home.

r? @jdm @paulrouget

[Manishearth]

One thing that doesn't work right now is that when you hit the home button on the start menu, we do not get any events, nor do we get any events when you tap the greyed-out servo window. This puts the session in a state where it's idle but can't be told that it should wake up again. Not quite sure what to do here.

According to Bryce this is a bug in the runtime, we should be getting READY when you tap the servo window. They hope to have this fixed by the next release (Jan).

[Manishearth]

Actually I'm not sure this is a good idea, this means the XR thread is indefinitely blocked while we're in the IDLE state, and since the XR thread is the main thread right now (@asajeffrey, can we change this for Hololens?) this means we're blocking the main thread too

[asajeffrey]

Yeah, this doesn't look great. I don't know if we can run the HL AR APIs off the main thread, it would be nice if we could.

[Manishearth]

Pretty sure we can, there's no documentation about main thread affinity

[jdm]

I specifically asked about thread affinity back when we were starting openxr and was told that openxr can run on any thread on the hololens.

[Manishearth]

Also, doing this completely inside handle_openxr_events isn't great; because now we can't receive quit events. It might be worth working this into the larger webxr event loop, though that would involve some tricky control flow.

So I'm thinking about this and I'm not really enjoying any of the approaches available:

---

Approach 1: Make the XR event loop handle this

We can split out poll_for_events() out of wait_for_animation_frame(), and have that signal state changes. When any device goes into an idle state, this stops handling frame requests, and instead only handles other messages as well as doing the "occasionally poll for events" that we're doing here.

This involves changing stuff all the way up to run_one_frame, which is ugly.

---

Approach 2: New thread

Spawn a new thread that loops and polls for events, and put the main thread in "don't listen to raf calls" mode where it just remembers all the raf calls it gets. This is ... okay, but it's ugly since a lot of OpenXR state stuff leaks into webxr-api.

---

Approach 3: double quit channel

The only thing we care about is the quit message, everything else can wait until the next frame. Perhaps we instead quit() send two messages, one which goes directly to the device which can be checked by the device. We can then use an approach similar to here. We'd still have to figure out how not to block the main thread.

@asajeffrey thoughts?

[asajeffrey]

If we can run the HL AR APIs off the main thread, would this get round all of this? In the medium term, we should probably revisit the embedding story to move as much of Servo as we can off the main thread.

[Manishearth]

@asajeffrey running things off main thread would let us pick Option 3, which is the cleanest.

[bors-servo]

☔ The latest upstream changes (presumably #133) made this pull request unmergeable. Please resolve the merge conflicts.

[jdm]

If we can run the HL AR APIs off the main thread, would this get round all of this? In the medium term, we should probably revisit the embedding story to move as much of Servo as we can off the main thread.

This question is doubly interesting now that we are running openxr in its own thread.

[Manishearth]

@jdm now that we've done this, approach 3 can Just Work, though i'm not super happy with it

[Manishearth]

Oops, reused a branch name

[Manishearth]

Superseded by #139