Then perhaps a WaitableTimer would do the trick

Waitable-timer resolution is the same as the system timer resolution.

In addition to what Bacterius and L. Spiro already said...

DispatchMessage may take an infinite amount of time if there's a modal window, a window displays a menu, or when processing some of the non-client events for any window.

Your concerns about forced power saving are all about laptops/notebooks - they are not founded when it comes to desktops. So why should a simple maze game (for example) need to throttle up my 3.4Ghz qad-core CPU to 100% all the time? There are even AAA games that don't need that much performance. Why should I always have to use the power saving features in Windows 7 to limit the CPU when I'm playing these games (just because I want my CPU to stay as quiet as possible)?

Can you take your Asus to 2Ghz by using prime95? A busy-wait loop that does nothing is a good reason for the laptop's CPU to do power saving.

Then perhaps a WaitableTimer would do the trick

Waitable-timer resolution is the same as the system timer resolution.

In addition to what Bacterius and L. Spiro already said...

DispatchMessage may take an infinite amount of time if there's a modal window, a window displays a menu, or when processing some of the non-client events for any window.

Your concerns about forced power saving are all about laptops/notebooks - they are not founded when it comes to desktops. So why should a simple maze game (for example) need to throttle up my 3.4Ghz qad-core CPU to 100% all the time? There are even AAA games that don't need that much performance. Why should I always have to use the power saving features in Windows 7 to limit the CPU when I'm playing these games (just because I want my CPU to stay as quiet as possible)?

Can you take your Asus to 2Ghz by using prime95? A busy-wait loop that does nothing is a good reason for the laptop's CPU to do power saving.

Except, you already have a built-in mechanism to limit your FPS, so there's really no point in manual-limit methods. Plus, you'll never be able to exactly get to 60FPS, and you'll start seeing tearing effects.

Yes, busy-wait can be useful at times, but most people tend to use it as a brute-force solution when it isn't needed. And unless you are writing a AAA game which requires high-end GPU, you can't assume that people will not run your games on laptops.

I would just dynamically switch to using WaitMessage, GetMessage or similar at times when the game is in pause mode, only showing a menu or has only need for updates in reaction to user input and no animations are running; that should reduce useless burning of cpu time and electricity already.

Maybe also use those timers that send a message on times of low activity. But using them constantly or adding sleeps I would think could give problems with timing, and vsync+measuring time+fixed timesteps for updates independent from drawing may be good enough? Though it could depend on the type of game and I did not see it mentioned by the OP.

Waitable-timer resolution is the same as the system timer resolution.

Do the he said what??

Citation needed.

A waitable timer as as accurate as any other event, which is nearly down to the microsecond.Though of course no guarantees.

Plus, a waitable timer will cause a waiting thread to be scheduled over its siblings by giving it a priority boost. Sleep simply makes a thread "ready" after the rounded-up time is over. Which means it may get to run some time later. On non-server editions of Windows, this usually means 2 quantums, since that is the default scheduler unit.

A waitable timer makes the waiting thread ready and higher priority at the exact time the time is up. Due to the way the Windows scheduler works (serving top-down by priority), this makes a huge difference.

It still does not guarantee that the thread will run immediately, but it guarantees that it will the the first one in its group of similar-base-priority thread peers at the next opportunity. It also means that it may interrupt a peer thread before the assigned number of quantums are over.

Waitable-timer resolution is the same as the system timer resolution.

Do the he said what??

Citation needed.

A waitable timer as as accurate as any other event, which is nearly down to the microsecond.Though of course no guarantees.

L. Spiro

Well, I don't think Microsoft broke it's terse power-saving rules just to make this specific type of timer more responsive... Then again, I never used it, but I have used an tested (against QPC) most of the other thread-sync events, and they all ran at approximately the system-timer resolution (15ms by default). I then also found some articles that mentioned this - can't remember where, so I don't think I am mistaken about waitable timers, really. But I'd be more than happy to be proved wrong.

A waitable timer makes the waiting thread ready and higher priority at the exact time the time is up.

That doesn't help much, for two reasons:

1) Most games already use the highest process&thread prioritiy available

2) The thread becomes active between intervals of the system timer - you can only hope that it becomes active sooner than later.

MSDN said
High-frequency periodic timers keep the processor continually busy, which prevents the system from remaining in a lower power state for any meaningful amount of time. This can have a negative impact on portable computer battery life and scenarios that depend on effective power management, such as large datacenters.

Exactly my point - so why would they make only the waitable timers high-performance, then? Everyone (mostly game developers) would just start using them, and that would defeat the purpose of that MSDN warning. Not that you can't use timeBeginPeriod(1), of course, but that's what the warning is for in the first place.

Windows would be slow as hell if there was no alternative. When you call WaitMessage() it internally performs the same kind of waiting, and if it was only as low as the system resolution your mouse would be jittery as hell.

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, and it all happens separately from the system timer's programmable interrupt, which only signals the CPU periodically. So, WaitMessage will return when either the timeout expires (as timed by the system-timer), or when a device-driver responds to a hardware interrupt event, and creates an input event from it (and so on)...

I still say that the waitable timers are just software timers backed by the system timer - in which case, the only way to increase their resolution would be to increase the system timer resolution.