0.7 SDK sleeps in submitFrame

Figured out that it was a Qt Bug, Qt looses events when using a QTimer with low interval settings.

Thanks for following up.

Sadly this does not fix the poor performance we get with the 0.7 SDK. Having the QTimer set to 2ms (so limiting to 500fps) does render with the oculus but there is still something wrong in the submitFrame.

When I move the mouse, the submitFrame basically stalls, it looks like it is waiting for all mouse-move events do be finished before it actually does it work. This is happening no matter if the application was compiled and linked against the 0.6 lib or the 0.7 lib, as soon as the 0.7 runtime is used the oculus seems to get blocked by events.

Another thing I noticed is the much to high brightness in the rift when linking against the 0.7 SDK. Mirror Texture looks fine but the rift display is way to bright, a bit like the gamma correction was applied twice.

I'm still debugging into it but I think I might be facing something similar. Do you have any information on the Qt bug and is it being tracked? I'm currently using Qt 4.7.4 and I'd like to figure out if it's affecting me.

Regarding the brightness, are you using SRGB for your textures? This seems to be a new requirement for 0.7; see the comments on ovr_CreateSwapTextureSetGL / ovr_CreateSwapTextureSetD3D11.

I have reported the Bug to the QT Bugtracker, although specifically tied to the Oculus since we also had this issue with another thirdparty lib. I am currently trying to build a simple example with the oculus lib.

The sRGB stuff makes sense, guess I overlooked that in the release notes. Guess that will fix the brightness issue, I just hope it will not break our color management pipeline which is a bit more advanced than just having a simple sRGB.

Just for the record it looks like it was QTBUG-48025 (https://bugreports.qt.io/browse/QTBUG-48025) that you reported right? I'm not sure because that bug sounded like it was for a licensing library and not OVR.

Yes, that was the issue I reported. The main issue for us was with the licensing library but it seems to be related to what happened with the oculus lib as well. When I had the QTimer at 0 the new Oculus would not render at all or just show the health warning. After changing the timer to 2ms it would at least render but with terrible performance (maybe 20fps on a scene that used to render with steady 75fps with 0.6SDK and 250fps in mono) and would stop rendering while moving the mouse cursor.

My guess of what happens is (at least I hope it is): The new SDK tries to move the oculus update to a thread so that it gets a steady 75fps even if the application does not deliver the frame in time so that instead of missing an update it timewarps the last frame to the current position. Great idea in general but it looks like the thread is put to sleep during the wait for the next update and is not woken up in time for whatever reason.
But of course this is just a speculation.

I am facing a very similar problem with my Cinder/OpenGL integration: ovr_SubmitFrame hangs, either right from the start or after 5-10 seconds of 'juddery' runtime. (Unrelated to mouse events.)

https://github.com/num3ric/Cinder-OculusRift/

I also had this problem with Cinder & the Oculus 0.7 SDK, found out that it's caused by using ovr_SubmitFrame on draw(). It seems that ovr_SubmitFrame sends another WM_PAINT message which causes ovr_SubmitFrame to be called recursively, causing it to lock(I assume some sync object locked by the previous call).
Moving the rendering code to update() will fix the issue.

"daemeh" wrote:
I also had this problem with Cinder & the Oculus 0.7 SDK, found out that it's caused by using ovr_SubmitFrame on draw(). It seems that ovr_SubmitFrame sends another WM_PAINT message which causes ovr_SubmitFrame to be called recursively, causing it to lock(I assume some sync object locked by the previous call).
Moving the rendering code to update() will fix the issue.

Thanks for looking into it! You seem to be absolutely correct. Is it expected/documented that ovr_submitFrame emits WM_PAINT messages? I've started to explore the solution you proposed on a branch called 0.7-fix.