It’s complicated and has a learning curve, but not terribly hard overall.
The main reason for these complications is backward compatibility. Windows 3.x only supported a single CPU core and had cooperative multitasking. Windows 95 had preemptive multitasking, but only supported single core still.
> it's a classic race condition
It’s not a race condition because windows have thread affinity. All these messages, WM_SIZE, WM_PAINT and the rest of them, are serialized by the OS into a single queue consumed by the thread who owns the window.
I did not mean a thread race condition. Classic was the wrong word. I mean race condition between acquiring a swapchain (for the current window and size) and finishing drawing to it. There is no way to stop the compositor from updating the window in between. The correct way of doing would be to change the window sizes when presenting the new swapchain.
It’s complicated and has a learning curve, but not terribly hard overall.
The main reason for these complications is backward compatibility. Windows 3.x only supported a single CPU core and had cooperative multitasking. Windows 95 had preemptive multitasking, but only supported single core still.
> it's a classic race condition
It’s not a race condition because windows have thread affinity. All these messages, WM_SIZE, WM_PAINT and the rest of them, are serialized by the OS into a single queue consumed by the thread who owns the window.