I still have nightmares battling the win32 windowing system. Look at all the window when resizing, how they stutter, streak, flip. That's the broken windowing system. At it's core, it's a classic race condition, the window size, controlled by the os is updated, the software needs to repaint it, if it doesn't do it before the next compositor redraw, yikes.
Sadly, nobody seems to care and microsoft "fixed" it in UWP.
The win32 window system gives you a lot of options, and it's sometimes hard to figure out what combination of callbacks/flags you need.
Windows shouldn't be stuttering or streaking if you do it right, which applications like Windows Explorer and Chrome do correctly. Applications like Skype and Discord seem to paint the whole window using some widget library, so they have redraw issues while resizing the window.
Uhm.. what windows are you using? Win 10 Chrome does "lag" if you resize the window. It's very noticable, but people seem to accept it.
Windows explorer is almost perfect. But even that one sometimes draws the old sized content if you resize the window.
Sublime seems perfect, Visual Studio stutters quite badly.
I use a Vulkan Swapchain, to get a swapchain image, you have to say for which window and must use the current size, then you can do all the drawing and present. If the compositor decides to update inbetween, it will show the old swapchain image with the new window size.
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.
That's because win32 was developed before graphic cards in PCs were a thing. They made a design decision to make the application own redrawing the window if it got overdrawn.
I see MacOS windows freeze up all the time with the beach ball.
Current GUI frameworks are based on a leaky abstraction in that there is a single drawing thread and if that thread hangs the UI hangs. (e.g. as all the classes and objects are using the same resource to get work done, any of them can stop any others from doing anything at all despite private/protected/encapsulation etc.)
