The system timer has nothing to do with the mouse, or any other bus-connected device. Devices have their own interrupt that signal the CPU when a hardware event happens
Now you’re getting it!
Ever heard of a hardware timer? When it expires it causes an interrupt and signal, just like a mouse!
So, WaitMessage will return when either the timeout expires (as timed by the system-timer)
No. A message sent is always a signal, and signals are always virtually immediate (measured in microseconds, not milliseconds).
In a standard-issue timer, the delay between its trigger time and the Windows message to handle it (WM_TIMER) is off by a large amount simply because the timer itself used a low-resolution clock for its trigger, not because the signal (message) was delayed by a low-resolution clock.
If you set a thread to wait for a signal and then you do a task and then send the signal, that thread will get the signal almost immediately, and all Windows messages are based on the signalling scheme.
Hardware timers cause an interrupt that causes a signal that cause an almost immediate response.
Since most systems only have one hardware timer, the operating system uses it to signal the next-in-line timer (taking advantage of the hardware interrupt), then reset the hardware timer to the amount of time left on the next-to-fire timer etc., allowing any number of timers to trigger via hardware interrupt, regardless of the system timer.
This can introduce a slight amount of drift as shown in Hodgman’s experiments; his fired in 0.1 milliseconds worth of drift, but in fact that is just the accumulated error as the operating system readjusts the hardware timer for multiple other timers before finally getting to his. If his is the only timer on the scheduler, it would likely have had a drift of only about 10-20 microseconds.
And then there are of course regular timers which are indeed based off the system clock. These exist as a power-saving way to implement timing when drift is not such a large issue, because the more timers you put on the hardware timer the more drift you get, and this it is generally assumed that the hardware timer should have as little drift as possible.
Hence the only way to use the hardware timer is via SetWaitabeTimer().
so why would they make only the waitable timers high-performance, then?
Everyone (mostly game developers) would just start using them
Most people don’t even know about SetWaitableTimer().
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums