See what Microsoft says about using TSC and/or QPC
Alas, this is irrelevant to the problem in question, Patrice.
First, we need a self-calibrating clock (in fact, a stopwatch, not just a QPC counter!) that should trigger system events regardless of CPU clocks, based on Mother Nature's
absolute time intervals (not CPU clocks per second!) at a rate slightly higher than the monitor refresh rate (144Hz, or 144 events per second, at the "worst" case). Believe me, that's a non-trivial task at all under any of Windows OS'es which in fact
aren't realtime systems. Continuous rendering based on InvalidateRect() in every WM_PAINT message handler is too crude for this task because WM_PAINT has higher "priority" than WM_TIMER, and it overloads the CPU message pump even if it doesn't actually paint anything due to WM_PAINT's own low priority relative to other window messages.
The slightly extra frequency rate of such a clock will then be normalized by OpenGL VSYNC down to the monitor's actual frequency (144Hz) to avoid image tear -- with minimum overload on the window message pump, pretty much like ObjReader's current Windows timer-based "heart pacemaker" works.
Second, we will have to somehow mimic WM_TIMER's behavior in the message pump where it has a "synthetic priority" lower than any other window message
except user-interactive "hardware interrupted" messages such as mouse moves and mouse/keyboard button clicks or wheel rotations. Our own custom message will then trigger OpenGL canvas renders in its own handler exactly like the original WM_TIMER did but at a considerably higher yet stabilized "turbo" rate/speed/pace.
Do you understand the nature of the problem better now, my friend?
