Loop timing of OpenTK

[Timing]
Calling Run like GameWindow.Run(30.0, 60.0), guarantees exactly 30 UpdateFrame events per second. If the computer can't handle the requested UpdateFrame rate, RenderFrame events will start being dropped in order to maintain it.

Up to 10 RenderFrame events will be dropped this way. If the computer still can't keep up (i.e. it falls below 6fps in this case), you'll see the UpdateFrame rate to start dropping. The correct approach is to define your program's minimum requirements so that this never happens - that's what commercial games do ;)

Obviously, the higher you set the UpdateFrame rate, the more difficult it is to maintain.

Now, the logic behind GameWindow is accurate enough that you can use exact values in UpdateFrame events:
speedX += 2.0f;

Obviously, you shouldn't do this in RenderFrame events, since their rate is much more variable (by design). In any case, everything depends on your design:

• You could use variable rates and deltas everywhere, which has the advantage of scaling nicely to higher frame rates (smoother movement), but is more CPU intensive (divide everything by delta) and more prone to numeric instabilities.
• You could use fixed rates everywhere, which is simpler but will not look good if the UpdateFrame rate is lower than the RenderFrame rate (jerky movement).
• You could use a fixed UpdateFrame rate and a variable RenderFrame rate, and interpolate object positions in the RenderFrame event to obtain smoother movement. Once again, this is more complex but would give the best of both worlds.

There is no clear-cut solution to these issues. You'd have to experiment and pick the one that works better for the program you are going to make.

You can consider e.Time as the percentage you want to step (assuming 1.0 == 100%), so if you want to have an object rotate 90° per second you'd calculate something like this: Angle += 90 * e.Time;