Sleep() and ofSetFrameRate accuracy

Hi guys,
Here is something strange I am fighting with the last few days. I have a PointGrey Flea3 cam, which could run at 120 fps. I am trying to run a basic application under Windows 7, using their FlyCapture SDK, although the problem I am having is also present, if I run just the basic empty example application.

Basically I am doing this, at the setup() of my application, I would set:

ofSetFrameRate(120);
ofSetVerticalSync(false);

and what I would get is Openframeworks running at no more then ~64 fps. The really weird thing is that sometimes after a while, the application will start running at my desired rate, but if I restart, I am back at the ~64 fps limit.

So, I dug deeper into the matter and I noticed the Sleep() method inside the ofAppGlutWindow idle_cb function. When I set the frame rate to 120 fps, the idle_cb function correctly calculates that it has too sleep for 8ms and waitMillis is indeed 8ms, but for some reason the Sleep function could not get lower then 16 ms sleep, which I measured using a suggested on the forums more accurate timer - QueryPerformanceCounter. So, I guess the problem here is the resolution of the Sleep method and the most weird thing is that sometimes it would work, sometimes it would not. I tested this on my MacBook Pro and on my Desktop machine, so I guess it's not hardware related.

I did another test too, setting ofSetFrameRate(0), bypassing the Sleep function. But then I get a resolution problem with ofGetElapsedTimef(), I still could not get a difference between the frames lower then 16ms. So I did another test with QueryPerformanceCounter and measured it against the ofGetElapsedTimef() inside the "update()" function and what I noticed is that when I set the FlyCaptureSDK to 120 fps, the application was indeed running in 120 frames per second, but OF was showing ~64fps. Basically the difference between frames using QueryPerformanceCounter was 8ms, but the difference measured with ofGetElapsedTimef was 16ms. Once again I should mention, that sometimes after like 10 minutes, I would get the resolution and the application showing correct frame rate, but when I restart it will be back at the ~64 fps limit.

Does anybody actually have this problem, is this a known issue or am I doing something completely wrong here?

Here is the QueryPerformanceCode, I am usuing for measurement:

class Timer {
public:
    double PCFreq;
    unsigned long long CounterStart;

    void StartTimer() {
         LARGE_INTEGER li;
         if(!QueryPerformanceFrequency(&li))
            cout << "QueryPerformanceFrequency failed!\n";

         PCFreq = double(li.QuadPart)/1000.0;

         QueryPerformanceCounter(&li);
         CounterStart = li.QuadPart;
    }

    double Timer::GetElapsedTime()
    {
        LARGE_INTEGER li;
        QueryPerformanceCounter(&li);
        return double(li.QuadPart-CounterStart)/PCFreq;
    }

};

Keep up the good work,
Kamen

Start by inspecting the ofAppGlutWindow idle_cb implementation, especially Sleep timing and waitMillis, then review ofGetElapsedTimef() and the reported QueryPerformanceCounter measurements on Windows. Reproduce the 120 fps and ofSetFrameRate(0) cases if possible; done means the frame rate and elapsed-time reporting behave accurately at high rates.