CloudXR 3.2.2 has worse video quality

We fixed an image quality issue that was our fault (using the recommended width/height for the swap chain but the display res for the CXR video stream, which resulted in a blurry final image due to downscaling).

But, enabling this flag still yields an unstable app, the video stream hangs after a few minutes. It’s 100% repro, and unreliable for us. I would love the extra performance (or rather, battery life savings, as it runs fine at 120 Hz regardless), but not at the expense of stability. Also, at certain resolutions, the image flips upside down using that flag but not when it’s disabled. I am pretty sure there are bugs in it.

This is using OpenXR on Quest, not OVR / VR Api, so the code is completely different than your code sample but we tried to keep all the relevant CXR parameters the same (sometimes making mistakes along the way, but they’re mostly solved). I’m just curious, do you still have plans to make your own OpenXR-based client? or is that still a ways off. It would be nice to compare implementations.

so really quick response:

  1. glad you found quality issue that was downscaling, It’s never going to be perfect match, as steam plays with resolution whenever it wants. :)
  2. we’ve not had any experience with imagereader decoder on quest2 hanging after a few minutes. I would sit here and play alyx, superhot, etc, for 20, 30, 40+ minutes in a session easily. And I don’t know about the image flipping, never seen that. I’ll note we also don’t run 120hz, so that as well is a variable I cannot account for atm.
  3. if you are using openxr, you’re outside our realm of experience at the moment. We do have plans to do an XR client, but my guess is it’s still a ways off.

Most issues we encountered in the past were corner cases, timing related, buffer availability related, missing (or locked) mutex, etc.

I’m pretty sure the hanging / instability issue also happens even in your 3.2 Vr Api Quest sample, when Quest 2 is running at 90 Hz which enables the advanced image decoder. I will double check. It could be a side effect of a recent update to SteamVR, who knows. We use the OVR 3.2 sample as well, a lot, but it’s still locked to 72 hz which doesn’t enable the flag. I’ll double check this using your sample with nothing else changed except forcing it to use 90 Hz instead of 72 on Quest 2, or even just keep it at 72 Hz but force the flag enabled regardless of the refresh rate. TBH I’m not sure why the current sample only enables it above 72 Hz, as if it’s stable and more efficient, shouldn’t it be always-on? I’m not sure what the thinking is behind this.


If I force the flag being used at all refresh rates, on Quest 1 the image is flipped upside down. This is definitely a bug.

Also, on Quest 1 and 2, and Quest 2 at certain resolutions (regardless of the above flag), there are wavey vertical lines when you enable foveation (-f 50). Disabling foveation looks overall worse / blurry, but there are no distracting wavey lines. This is 100% repro, and in your sample code, not related to our implementation at all. (though we experience the same issues). We have to fine-tune the resolution to avoid the wavey lines but the defaults are no good on Quest 1 (1440 x 1600 per eye res, what’s used for CXR stream)

Can you repro this and get back to me?

I get the image flipped upside down on Quest 2 as well, at certain resolutions, when that flag is enabled (> 72 Hz). It seems clear to me that this is an experimental flag that isn’t ready for prime time yet.