XR_EXTX1_event_channel public experimental preview

[WenlinMao]

This is a public experimental preview of the upcoming XR_EXT_event_channel extension. It is provided to the public to gather feedback, and some XR runtimes might support it for a limited time, until we have a finalized version.

Any feedback can be submitted as comments to this pull request, or in the Khronos Slack channel.

Extension Overview: The OpenXR 1.0 event model is very simple. There is a single implicit event channel per instance, and the application polls it for events via xrPollEvent. This design is sufficient for limited use, but introduces extra burden on modular application code making use of events for disparate purposes, as it is the application's responsibility to route any events to the module or modules that need to handle the event. This extension expands on the OpenXR event model to add support for multiple separate event channels. These event channels are created and destroyed by the application, and they can be polled independently. Operations that generate events may also optionally allow the application to specify the event channel where the events will be delivered.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Wenlin Mao seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Ralith]

I don't understand what problem this extension is solving. Applications can already easily dispatch events themselves by whatever mechanism they like, such as by using off-the-shelf message-passing data structures. Baking this functionality into OpenXR complicates runtimes apparently without enabling any new uses. It should not be the responsibility of every OpenXR runtime to independently re-implement readily available data structures even when most applications would find them useful, which does not seem to be the case here.

[rpavlik]

I think this is likely to be most helpful to folks using a game engine that might already process the basic events. An app developer could create an event channel for events from a specific extension, etc to not have to bounce them through the engine, etc. (Events are basically the main way of asynchronous notification in OpenXR, so there's lots of things that could be made cleaner if you could e.g. send "model load" messages to a specific queue instead of getting mixed up with session state changes, interaction profile changes, reference space changes...) This is another one of those extensions that's not super useful on its own, but that will be built upon by other extensions.

Thanks for the feedback! Based on the enthusiasm in the group, I don't think the runtime implementation will be the hurdle, but it does look pretty useless on its own.

[Ralith]

If an engine already exposes a mechanism for an application to enable unknown extensions, it seems like a very small additional step (smaller than the introduction of this extension) for it to also delegate unhandled OpenXR events to e.g. an application callback.

[lionleaf]

Hi @Ralith,

Thanks for taking the time to look at this and giving your feedback.

One of the key scenarios an extension like this enables is to make it a lot cleaner to write engine-agnostic libraries that rely on OpenXR events; the library can consume its own events without needing the library user to manually pass the relevant events through whatever event passing system it uses.

It is also a significant benefit for engines to avoid having to build such a system to move events between threads, when the relevant code can create a channel for the specific events that are relevant to that subsystem.

(And, it's optional to use this functionality)

[Ralith]

The case for libraries makes sense, thanks for the context! In particular, this should permit faster/more consistent event delivery to a separate thread than any approach which requires centralized application-side dispatch. Thinking in those terms, this might even be useful for monolithic applications, given sufficiently latency sensitive events.