PocketMatrix

Your basic loop is fine.

If I were using C++, I'd probably hold a list of objects that responded to input and define a virtual function in an ancestor so that I could provide the objects with their input (sounds like PocketFrog's way of doing things, from your desription - I've not looked it PFrog). Actually, if you didn't have many objects that you throw input at, it might be cleaner to use multiple inheritance for those objects to get their input function.

I wouldn't check the input per object. Just have a loop after the input that throws it at all of the relevant objects...

I probably wouldn't make an "input controller" because the coupling would be too high.

1) is probably not a good idea. I'd go for the method where you're looking after time-keeping, not the OS. Imagine if the even occurs before you've finished processing - you'll get a back-log of WM_TIMER events to deal with (I think - don't quote me on that)

To help performance:
If you use double/triple-buffering, you can start working on the next frame while you're waiting to display the last - that way "expensive" frames don't cause as much stutter as they would if you were waiting until the next (artificial) vsync. The added latency of one frame normally isn't noticable.

When the draw queue is full, you are going to have to "wait"... but if you find you're waiting lots per frame, then do more cool stuff!

Cheers,

Ref.