you should be able to use vr::VRCompositor()->PostPresentHandoff(); for this, but it does not work either, if vr::VRCompositor()->WaitGetPoses(...) is not called

Thanks for the reply!
So we have to call WaitGetPoses() even when it drops FPS to 45, and there is no way to get around that function? Guess we will have to use reprojection then...

Did not find any way, but pushing data is running in a separate dedicated thread in my environment. So I just don't have to care about wasted wait-time. You may also try disabling v-Sync.

Thank you very much TheWhiteAmbit :)
We have decided to use ForceInterleavedReprojectionOn() for now to reproject 45 to 90 for now.

I am developing an app using OpenVR sample named 'hellovr_opengl' as the base code. The API call WaitGetPoses() drops the FPS to 45 or so. I have few questions to solve this problem properly.
1)WaitGetPoses() is being called in the main render thread. Is that how it should be used? Do we have to call from the render thread?
2)I created a separate dedicated thread and called the WaitGetPoses(), which did not help me much, since it updates tracked device poses, the render thread still had to wait for the dedicated thread to finish, so that it can use Hmd pose matrix. The framerate was still not 60 and I could see stuttering of the display whenever there was a hmd pose update.
3)I tried to use GetDeviceToAbsoluteTrackingPose() instead of WaitGetPoses(), but nothing was displayed on the device.
4)What does ForceInterleavedReprojectionOn() method do? There is no documentation on this method. And how and where to call it? (I saw that this method was a solution for the other member(mintslime).

Note: Vsync has been turned off.

Any kind of help or suggestions will be greatly appreciated! :)

I was not able to fully solve the problem and we eventually used oculus instead, but here is what we learned from our experience.

1. WaitGetPoses() should always be called, there is no way to skip it
   2.Yes, you will need to call WaitGetPoses() on render thread (see this posst: http://steamcommunity.com/app/358720/discussions/0/385429125016008605/)
2. PostPresentHandoff() might help with the performance (see this post: http://steamcommunity.com/app/358720/discussions/0/405691491122676152/)
   4.Turning on reprojection is as simple as adding this line to your initialize function:
   RCompositor()->ForceInterleavedReprojectionOn( true );
   It works if your game runs at 45 fps consistently
3. You don't want the framerate to be 60 on openVR, from their old talk, it should either be native 90, or 45 so interleaved reprojection would work. Interleaved reprojection looks really bad if your framerate is higher than 45 but lower than 90.

Thank you so much, mintslime! :) I will give it a try soon...

2. is not completely correct. you can decouple the render thread and have another one pushing just the frames to openvr. so it is more like WaitGetPoses() should be called in the vive thread, but technically this does not have to be the render thread. We gain good performance by not waiting in the render thread, but at the cost of lag. if treads are linked via a mutex we do not have the lag, but the frame time prediction is sometime that bad, we get judder and false positioned frames instead.

Thank you for the reply @TheWhiteAmbit ! I tried to do what was suggested like having two threads( main thread and render thread). Main thread just calls WaitGetPoses and keeps looping and render thread gets the poses by calling GetLastPoses and calls OpenGL commands and then submits both the eye textures to the compositor and call PostPresentHandoff and then call the swapbuffer method. Since both the threads are using compositor object pointer they have to wait on the mutex, which makes the framerate to drop to the extremely low value. Am I missing anything here? How to solve this WaitGetPoses issue?
Any further help would greatly appreciated.

Can a Valve developer comment on this? I also want to know what is the best way to deal with calling WaitGetPoses if manual calls are being made to GetDeviceToAbsoluteTrackingPose (for whatever reason). I don't want to post a duplicate issue, but our project calls for manually adjusting the prediction intervals, and we need total control over the latency. Aaron Leiby also directed developers on Steam to consult the following link for details about order of calls, but the page seems to be blocked. https://steamcommunity.com/groups/steamworks/discussions/20/357288572132086689/

It seems I've had some success with following an obligatory WGP call with a GDTATP call of my own, but it's hard to tell if I'm not doing it wrong. I'm still somewhat confused about what is the correct way to use PostPresentHandoff to achieve different results, as alluded to by @aleiby here: http://steamcommunity.com/app/358720/discussions/0/405691491122676152/#c405691491129025734

Since I need the renderings of another renderer-thread, I am forced to do the two thread approach. You are correct on the mutex eliminating possible advantages. However, timing on the image-rendering thread can be still varying from multiple images per frame to none. Since it is possible to have very exact control over provided calls in hmd-thread, I played a little bit with the OpenVR-API. If you don't submit new frames at all while calling WaitGetPoses() there seems to bee some perfect rotating timewarp function (maybe it is even async, but this does not really matter). Just one thing is odd with this, the rotation on quad-overlays is inversed, position correct. Also the edges are not clamped to black, so some strange effects happen at ~90° off center. I still have some odd timing behavior of OpenVR occuring..