I’d like to see better support for running multiple applications like overlays and utilities. Currently those are only possible through the extensions XR_EXTX_overlay and XR_MND_headless, but they have a lot of limitations. I touched on it a bit in this reply before: https://community.khronos.org/t/openxr-without-rendering-loop/108658/3
An issue I’ve come across is that there is no way to guarantee that the runtime has support for running more than one application at the same time. XR_EXTX_overlay suggests that it should, but doesn’t seem to have any text guaranteeing it. XR_MND_headless doesn’t even mention it, and testing with the implementation in the SteamVR runtime, an application launched with it will still quit if another application launches.
This could either be implemented as an interface to query whether the runtime is able to launch multiple applications, or an extension that guarantees that it will.
Probably unrelated, but tangential (I don’t know how off-topic this is) is this scenario:
I had a VR game running in the background, when I ran my project on top of it, not thinking about the fact that it would have to take precedence. It’s probably unrelated, but pretty much my project took over the WMR session, but the other app kept playing music, and when I exited out of OpenXR the game program stalled or crashed.
I suppose there’s a way to negotiate and yield, but I wonder if apps implement it, and I wonder if apps would really mind if xrWaitFrame just didn’t return until the superseding app exits out.
I think it’s entirely up to the runtime how to handle multiple applications. The SteamVR runtime will at least end the session of the first app when the second app creates its session.
I don’t think there is any way in the spec to negotiate between applications, at least I haven’t seen any. Instead of not exiting from xrWaitFrame, the intended way to toggle between applications seems to be to transition the unfocused one to XR_SESSION_STATE_VISIBLE or XR_SESSION_STATE_SYNCHRONIZED depending on if it should still be rendering.
It looks sounds like the app in question is not properly handling session events (the kind listed by Rectus above). The app is told that the session is ending for them, if it does nothing about it, bad things will happen
This is confusing, I actually thought FOCUSED was input related. (I mean it kind of is, but here it means the currently displayed app in the WMR model I assume) and SYNCHRONIZED and VISIBLE imply you’re focused but trying to determine frame timing for a smooth start, and there’s a head in a set that’s not asleep.
It really sounds like there is no nesting/stacking in this model and if an app is initiated the current app should just kill itself. I hope this isn’t too off-topic!
EDITED: I forgot, funnily enough right now I’m trying to wait for the WMR animation (and Cliff House) to end so I can quit/init with different super sampling factors. I hope waiting for VISIBLE will be adequate.
VISIBLE is supposed to mean that the application is visible but doesn’t have input focus. Maybe WMR is handling it wrong. SteamVR by default will transition into VISIBLE when the dashboard is up and eating the inputs, and will transition to SYNCHRONIZED when the headset is removed. https://registry.khronos.org/OpenXR/specs/1.0/html/xrspec.html#XrSessionState
Thanks for feedback. I think probably so. This is why I worry that every runtime is radically different. I’ve made a separate topic/thread for this since my tests with WMR didn’t go well (I kind of already suspected they wouldn’t.) (EDITED: I say there that WMR seems to always report VISIBLE/FOCUSED even when doing transitions or showing another app… or maybe “Cliff House” doesn’t count as an app but it looks like one.)
