How to get more accurate FPS without spinning the CPU.

Fiddler, this is the demo code that you asked for. Any thoughts?

Yes, this looks just about perfect.

I found a bug in the interpolator...fixed.
I removed the console.writeline stuff
I have tested this with all sorts of update / frames combinations and it appears to work pretty well.

Please let me know what you think.

I don't think I can assuage your concerns by explaining testing. I think it would be more useful to explain the technique. From there you should be able to comment on its general usefulness.

First, I think we both know the general problem with Thread.Sleep() is that on Window a call to Thread.Sleep(1) can take 15ms to complete. So basically we have low resolutions timers.

FPS is an average though. If I need to sleep for 20ms on average, I can approximate this by repeating the following sleep pattern

Thread.Sleep(15)
...
Thread.Sleep(15)
...
Thread.Sleep(16) // This is really behaves more like Thread.Sleep(30)

IE (15ms + 15ms + 30ms ) / 3 = 20ms avg sleep time.

The algorithm in InterleavedScheduler uses an adaptive logic (also called fuzzy logic) to continuously rebalance a sequence of sleep times to approximate average sleep times with higher precision then the available sleep timers.

The beauty of the algorithm is that it doesn't care what the timer precision is. This is because the algorithm learns the timer precision by changing 1 number in the sequence per "test" and observing the impact to the framerate. Since this is done continuously but with very low overhead, the algorithm can adapt to changing load conditions on the hardware.

Basically, if there is sufficient CPU capacity to achieve the requested frame rate, the algorithm will be able to learn the correct sleep sequence to meet its target.

A few things to note.

1) In this implementation, the sequence is hard coded to a length of 30 sleep times.
2) If there is insufficient CPU to meet the requested framerate, the algorithm will gracefully approximate a sleep(0) scheduling.
3) The range of sleep times in the sequence will never exceed 1 ms. IE low = 55, high = 56.
4) The sequence make a reasonable attempt to avoid clustering by oscillating between the high and low sleep times when possible.
5) The algorithm is very high performance and does not require per frame heap allocations.

It should be noted that by using a sequence of sleep times instead of a single sleep time, the elapsedSeconds value will vary from call to call. I do not see this as a negative attribute of the algorithm because the system will already include a large amount of non-determinism which will induce its own variance into the per frame elapsedSeconds. I have a design for a scheduler which can simulate constant per frame update times, but I'll save that for another day.

Well, as the thread title states, I am offering an alternative to spinning the CPU as a form of scheduling. The vsync case is worth consideration, but its beyond the scope of this submission.

I am still waiting to hear if Fiddler will accept this. I don't want to get to far ahead of myself.

Is this approach fixed-time-step-logic or non-fixed? Sorry for being so code-blind..

Well, I have done as much testing as I can think to do at various loads and with various target FPS. I am not seeing jitter or negative side effects. I really think you should make this available for additional testers. I am sure other will uncover things that I have missed.

I have also tested this with VSync on and off. The only noticeable, but obvious side effect, is that the algorithm can no longer achieve target FPS above the vsync frequency. It is still able to match target FPS below the vsync frequency.

I do think I have failed to communicate the adaptive nature of the algorithm properly. The important thing to understand is that this algorithm is continuously re-balancing. Varying CPU and GPU loads are not a difficult problem for this system to deal with. Or to put it another way, this system is specifically designed to deal with varying loads. The trade off that one is making with this algorithm is that you are sacrificing some precision and determinism. Logically, this would be unacceptable to balance ones checkbook, but is completely tolerable in a FPS scheduler.

I am not advertising this as a complete solution to someone interested in doing fixed time interval updates. I do think it is reasonably simple for someone to consume the update events in a way that simulates a fixed time interval scheduler. Considering the great amount of non-determinism in the hardware and operating system combinations likely to run OpenTK, I am dubious that a true fixed time interval update scheduler is practical.

I still need to complete the documentation that you requested. I expect to have it complete shortly.

Currently, I am consuming the InterleavedScheduler the following way. I would like your opinions on whether I should internalize the calculation of the updateElapsedSeconds and renderElapsedSeconds values into the InterleavedScheduler.

        public void RunSimple(int targetFps)
        {
            RunSimple(targetFps, targetFps);
        }
 
        public void RunSimple(int updatesPerSecond, int framesPerSecond)
        {
            if (disposed) throw new ObjectDisposedException("GameWindow");
            try
            {
                TargetUpdateFrequency = updatesPerSecond;
                TargetRenderFrequency = framesPerSecond;
 
                UpdateFrameEventArgs updateArgs = new UpdateFrameEventArgs();
                RenderFrameEventArgs renderArgs = new RenderFrameEventArgs();
 
                try
                {
                    OnLoadInternal(EventArgs.Empty);
                }
                catch (Exception e)
                {
                    Trace.WriteLine(String.Format("OnLoad failed: {0}", e.ToString()));
                    return;
                }
 
                Debug.Print("Entering main loop.");
                hasMainLoop = true;
 
                Stopwatch stopwatch = new Stopwatch();
                stopwatch.Reset();
                stopwatch.Start();
                int updates = 0;
                int frames = 0;
                double updateElapsedSeconds = 0;
                double renderElapsedSeconds = 0;
 
                InterleavedScheduler scheduler = new InterleavedScheduler(updatesPerSecond, framesPerSecond);
                while (!isExiting)
                {
                    bool shouldUpdate, shouldRender;
                    double elapsedSeconds = scheduler.Update(out shouldUpdate, out shouldRender);
                    updateElapsedSeconds += elapsedSeconds;
                    renderElapsedSeconds += elapsedSeconds;
 
                    ProcessEvents();
 
                    if (shouldUpdate)
                    {
                        updates++;
                        updateArgs.Time = updateElapsedSeconds;
                        OnUpdateFrameInternal(updateArgs);
                        updateElapsedSeconds = 0;
                    }
 
                    if (shouldRender)
                    {
                        frames++;
                        renderArgs.Time = renderElapsedSeconds;
                        OnRenderFrameInternal(renderArgs);
                        renderElapsedSeconds = 0;
                    }
 
                    double totalSeconds = stopwatch.Elapsed.TotalSeconds;
                    if (totalSeconds >= 5.0)
                    {
                        double ups = updates / totalSeconds;
                        double fps = frames / totalSeconds;
 
                        Console.WriteLine("Actual UPS={0:0.00}, FPS={1:0.00}", ups, fps);
 
                        updates = 0;
                        frames = 0;
                        stopwatch.Reset();
                        stopwatch.Start();
                    }
 
                    scheduler.Sleep();
                }
            }
            catch (GameWindowExitException)
            {
                Debug.WriteLine("GameWindowExitException caught - exiting main loop.");
            }
            finally
            {
                Debug.Print("Restoring priority.");
                Thread.CurrentThread.Priority = ThreadPriority.Normal;
 
                OnUnloadInternal(EventArgs.Empty);
 
                if (Exists)
                {
                    glContext.Dispose();
                    glContext = null;
                    glWindow.DestroyWindow();
                }
                while (this.Exists)
                    this.ProcessEvents();
            }
        }

Lastly, as VSync is itself a form of scheduler, should OpenTK offer the option of disabling the interleaved scheduler in favor of using a purely VSync driven update / render scheduler?

I have tried to avoid over-reaching with the scheduler. I am very open to suggestions on what functionality to encapsulate.

To my thinking, if you really just want to vsync, the execution path should not include calls to the scheduler.

With respect to raising events on behalf of GameWindow. I am not opposed, but as I said before, I didn't want to over-reach.

I nearly mentioned something like that.
I haven't looked at the code really closely, but from what I have looked at, I noticed is that it lacks the ability to tell whether things are being delayed without checking the fps value itself (which lacks accuracy for interpolating animation) or keeping a seperate timer.
Maybe that's beyond the scope of what is intended though?

Kamujin: Do you have any example of an app' (something extremely simple like a spinning triangle or something) using the InterleavedScheduler?

Is this class something that

1) will replace functionality in GameWindow
2) will be an option for GameWindow-focused app-development?

In either case I'd like to have some example code to see how it is used - but I can see that you don't want to spend time writing that until Fiddler decides where the code goes ...

I'm likely to use the code in any case, so keep up the good work :)

*moved to bug report*