Stabilization is disabled after resuming the app

[WikkidEdd]

Describe the bug

If you use the start menu to put the app into the background and then tap the app slate to resume it results in the stabilization being disabled.

To reproduce

Steps to reproduce the behavior:

1. Clone this git repo
2. Open Unity project
3. Switch to UWP build platform
4. Build application.
5. Switch solution config to Release and ARM64
6. Build and Start the application
7. Observe that the 3 cubes in the scene are stable when moving your head
8. Bring up the start menu and press the home button
9. Resume the app by pressing the app slate in the world (or from the start menu if the app slate doesn't exist yet).
10. Observe that the 3 cube are now unstable when moving your head

Expected behavior

The application should resume without stabilization being disabled

Your setup (please complete the following information)

• Unity Version 2020.3.19
• Unity OpenXR Package 1.2.8
• Mixed Reality OpenXR Package 1.0.3
• Holographic OS 20348.1018
• OpenXR Runtime Version 107.2108.5003.0

Target platform (please complete the following information)

• HoloLens 2

Additional context

[yl-msft]

@WikkidEdd Thank you very much on your report and bring this to our attention. I'm from the OpenXR team in Microsoft building HoloLens platform, and i'm very interested to help you through these issues.

I will respond to each issue individually. Your categorization is really helpful. This first issue about perf hit after resume is likely related to the 2nd bug reported below, but it's also the most obscured one. I'd like to follow up on this issue a bit later after the other 2.

BTW: my team built a sample project on GitHub, designed to help repro bugs in different areas. Would like to see your perspective on whether you see similar issues on our sample. It's also a good place to report bugs on GitHub if you'd like.

https://github.com/microsoft/OpenXR-Unity-MixedReality-Samples/tree/main/BasicSample

[WikkidEdd]

Thanks for the responses. I'll be sure to use the linked repo for reporting issues in the future. It's hard to find the right place for these more platform-level issues.

I dug into this specific issue a bit more to try and find a workaround. It looks like related to the depth buffer sharing, if I switch the stabilization over to planar reprojection the app remains stable after resuming.

It's probably also worth noting that in this test project when the issue occurs the whole image is unstable consistently, but in our actual app, we get slightly different behavior. It's like parts of the depth buffer are incomplete, so parts are stable and parts are jittering. I think this perhaps makes sense if you say the other issue is texture management related, perhaps what we're seeing in our app is an uninitialized depth texture being submitted for reproduction?

[WikkidEdd]

@yl-msft I can confirm that all 3 issues are present in your sample app.

[yl-msft]

You are right about the "depth buffer sharing" feature is related to the bug. The internal runtime bug ware investigating is also related to the depth texture processing process in OS. We think we found a workaround to this in the upcoming runtime, will ping here when we have this runtime is distributed in preview channel in Store.