add support for XRVisibilityMaskChangeEvent

[cabanier]

A good portion of the drawn pixels are actually never used by the headset.
This is because reprojection and because the displays are not perfect rectangles.

This event will provide the region that the experience should draw to. It may choose to not draw outside this region.
Testing on native shows that this can provide a 5-10% performance improvement.

This feature is an event because it is possible that the region changes. For instance, when the user chooses to cast their experience, the OS will indicate that the whole region is used. Otherwise the casted content will have black bars on the side.

/agenda

[cabanier]

Protoype three.js implementation: cabanier/three.js@aefbc5d

[Manishearth]

Should we have an attribute and an event, or just an event? How does one get the mask at startup?

[cabanier]

Should we have an attribute and an event, or just an event? How does one get the mask at startup?

I think an event is enough. The mask typically doesn't change over the lifetime of the session.
We don't get the mask at startup. The session need to be up and running before we can get it from OpenXR.

[toji]

I think what Manish is wondering, and I am too, is how does the developer guarantee that they don't miss the initial event? Otherwise I think handling it as an event only is fine because it makes the developer work harder to ignore future updates. :)

Also, based on your Three.js sample code it seems like under the hood you're requesting the XR_VISIBILITY_MASK_TYPE_LINE_LOOP_KHR geometry? I can see how you make use of that here but not all apps are going to have ready-to-use 2D geometry boolean operations at the ready. I would have expected that exposing the XR_VISIBILITY_MASK_TYPE_HIDDEN_TRIANGLE_MESH_KHR data would be the most generally applicable?

[cabanier]

I think what Manish is wondering, and I am too, is how does the developer guarantee that they don't miss the initial event? Otherwise I think handling it as an event only is fine because it makes the developer work harder to ignore future updates. :)

It would be the same for all the other events such as the one for controllers. They are typically not present at session startup and come in later.
Should the spec note that these event should be called early (ie in the session start event)?

Also, based on your Three.js sample code it seems like under the hood you're requesting the XR_VISIBILITY_MASK_TYPE_LINE_LOOP_KHR geometry? I can see how you make use of that here but not all apps are going to have ready-to-use 2D geometry boolean operations at the ready. I would have expected that exposing the XR_VISIBILITY_MASK_TYPE_HIDDEN_TRIANGLE_MESH_KHR data would be the most generally applicable?

The experience could do it with 2 operations (1 to write 0's to the depth buffer and then 0 to mask out the area). That would still be fast and negate the need to the geometry operation.

[Manishearth]

It would be the same for all the other events such as the one for controllers. They are typically not present at session startup and come in later.

Yes, and we have XRSession.inputSources and XRInputSource.gamepad. This means you can initialize the data your application needs, and hook the event listeners up to refresh methods.

[cabanier]

It would be the same for all the other events such as the one for controllers. They are typically not present at session startup and come in later.

Yes, and we have XRSession.inputSources and XRInputSource.gamepad. This means you can initialize the data your application needs, and hook the event listeners up to refresh methods.

Virtually no experiences do that though; they handle controllers creation through the XRInputSourcesChangeEvent handler.
I think XRSession.inputSources was a mistake and it would have been better to expose them as live objects through an event. A lot of experiences struggled with this and we still see some that run into issues with this idiom.

[Manishearth]

Hmm, and in the spec we do fire off a startup event to guarantee this. I guess we can do that.

[toji]

Very minor point of clarification: We don't have a startup event, it's just the promise being resolved. Functionally it serves the same purpose, though, and we do explicitly call out inputsourceschange events as being queued to fire after the promise resolves. If we follow the same pattern here we should be fine.

[Manishearth]

No, I mean that we fire off an inputsourceschange event at startup; that is the "startup event" :)

[toji]

Got it!

[Manishearth]

I think XRSession.inputSources was a mistake and it would have been better to expose them as live objects through an event. A lot of experiences struggled with this and we still see some that run into issues with this idiom.

I think the alternate also has a lot of footguns: if you do not attach an input handler at exactly the right time you miss out on the first event and have nothing you can do.

This is worse with multiple layers of abstraction; e.g. if there is an XR framework which wraps WebXR but is missing functionality around input sources or masks or whatever, your code must be able to hook into its initialization routine (and get guarantees that the initialization routine is called at the exact right time in the microtask queue); it is not sufficient for that framework to expose the XRSession object.

[cabanier]

I think XRSession.inputSources was a mistake and it would have been better to expose them as live objects through an event. A lot of experiences struggled with this and we still see some that run into issues with this idiom.

I think the alternate also has a lot of footguns: if you do not attach an input handler at exactly the right time you miss out on the first event and have nothing you can do.

We're already there. Experiences use the events to handle controller generation; they don't just look at the attribute.

This is worse with multiple layers of abstraction; e.g. if there is an XR framework which wraps WebXR but is missing functionality around input sources or masks or whatever, your code must be able to hook into its initialization routine (and get guarantees that the initialization routine is called at the exact right time in the microtask queue); it is not sufficient for that framework to expose the XRSession object.

That is true but I would think that a framework would provide the necessary hooks so that the dev can intercept them.

[Manishearth]

We're already there. Experiences use the events to handle controller generation; they don't just look at the attribute.

I don't think this statement can be made broadly about all users out there.

And I think it's a bit of a failure of API design for users to have to ask themselves if they can guarantee an event at startup, paging through spec details to figure that out. The fact that the XRSession promise resolves before inputchange events is a subtle spec detail that matters greatly for users because of this design, but at least with the attribute they can choose to initialize their controllers by the attribute and use the event handler for updating it.

That is true but I would think that a framework would provide the necessary hooks so that the dev can intercept them.

Yes, but now we have this new mask event. Existing frameworks don't have the hooks, so one must update the framework if they wish to use it, even if the framework exposes an XRSession.

[cabanier]

We're already there. Experiences use the events to handle controller generation; they don't just look at the attribute.

I don't think this statement can be made broadly about all users out there.

And I think it's a bit of a failure of API design for users to have to ask themselves if they can guarantee an event at startup, paging through spec details to figure that out. The fact that the XRSession promise resolves before inputchange events is a subtle spec detail that matters greatly for users because of this design, but at least with the attribute they can choose to initialize their controllers by the attribute and use the event handler for updating it.

There are no inputsources in the attribute when the session promise resolves. Those get added when the event fires.

That is true but I would think that a framework would provide the necessary hooks so that the dev can intercept them.

Yes, but now we have this new mask event. Existing frameworks don't have the hooks, so one must update the framework if they wish to use it, even if the framework exposes an XRSession.

I think that's ok. It's very unlikely that the clip will be used outside the framework.