Showing results for 
Search instead for 
Did you mean: 

ASW Black Bar Flickering in Each Eye (OpenGL)

Honored Guest
We've had problem free Rift support in our application for well over a year, but ever since the update that enabled ASW for everyone we've had an issue appearing for anyone with a video card and driver that supports ASW. The issue only appears in our application when ASW is active and only in the Rift (not our mirror window), as our rendering engine owns the textures we render to and we copy them to the Rift's texture swap chain before submitting them. The issue appears as a black bar, towards the center of the Rift, taking up 1/3 to 1/2 of the screen in each eye, every other frame. Strangely, if our application has run recently before running the OculusRoomTiny (GL) sample the issue displays in the sample's mirror window when ASW is forced to active.

In the sample, the bar is flickering every other frame in the headset, but solid in the mirror window. If our application has not run recently then the result is normal, even when ASW is forced on.


I'm not sure what could cause this, our rendering engine developer has an Oculus sample which does not have this issue. I've been comparing our VR implementation to both our manufacturer's sample and Oculus' sample, but I don't see any differences that I can imagine causing the issue, at least none that I haven't already tried changing.

Knowing what the cause is, and being pointed in the right direction sure would help.

Without looking at the code or rendering my first guess is you're binding and copying to the wrong surfaces in the texture set. This is adding latency when running at the full 90 fps and when running at exactly half rate is showing the clear and partial rendering.

Can I get access to the app to experiment with it?

Honored Guest
After some more debugging I narrowed it down to an issue with monoscopic rendering. Our rather large CAD application doesn't have a particularly high performance 3D renderer, so by default stereo rendering is off. But since the condition seemed to be contagious between OVR sessions, turning on stereo rendering after previously rendering in mono never appeared to make a difference. However, by chance I started our application with stereo enabled, prior to performing any monoscopic rendering, and the issue disappeared.

On further investigation, it seems to happen whenever I set the second ovrLayer.ColorTexture to NULL, which is how to share a single texture between both eyes according to OVR documention.

As a workaround I can copy the mono image to a second texture swap chain and simply assigned it to the second ovrLayer.ColorTexture, as you would for stereo rendering. I wonder however if there's something else I'm missing in setting up for monoscopic display on the Rift (as it's not particularly well documented), or perhaps there's just a previously undetected bug with ASW, as monoscopic rendering isn't that common?