|
|
|
|
|
by Scali
1119 days ago
|
|
Exactly. As I tried to explain, you NEED a context switch (which doesn't make it a spin-wait) in order to avoid the deadlock between your main loop and the processing of the Windows message queue (and as you see, I do check the quantum, via QueryPerformanceCounter()).
The goal was to find a way that didn't deadlock the system, while also not wasting so much time that it impacts your framerate to the point where you can't even drive a high-refresh display at say 144 Hz. Ofcourse I'm open to even better solutions, but so far this is the best solution I know of. I doubt that events/semaphores would work better, as they'd be implemented as spinlocks for short periods of time, in which case they wouldn't actually trigger a context switch. Once you use a long enough time to get to a context switch, it's probably going to be worse than doing the context switch explicitly, the way I do here. All in all, it's a bug in Windows Aero, as the followup blog expained (not sure if it was ever fixed in later versions of Windows, I haven't been working with multiple display adapters/screens in situations like these in recent years):
https://scalibq.wordpress.com/2012/03/28/the-story-of-micros... |
|