On day 29 at 19:49 minute mark, @cmuratori says, that because the patblt happens before the stretchDIBits if the page-flip happens in between the two calls we will see a flicker.

I don't get what page-flip means here. I can only assume he means repainting of the frame. But, isn't the Win32DisplayBufferInWindow function called on every frame? If so then how can a page-flip happen while that function is still running?

The timestamp in the video when he gave the explanation: https://youtu.be/EwhVulgF16g?list=PLnuhp3Xd9PYTt6svyQPyRO_AAuMWGxPzU&t=1163

We don't control when Windows will switch between the two buffers. And there is no guarantee with Handmade Hero (at that point) to be sure that we are "in sync" with when Windows will switch buffers (we don't wait for the monitor vsync).

What Win32DisplayBufferInWindow does is only copy memory in the current buffer, but that doesn't mean that the buffer will be displayed to the user at that point.

It's also possible (but unlikely) that a frame wouldn't be displayed at all if our timing is a bit off: if the page flip happens just before the StretchDIBits (frame n) and our timing is less than 16ms (for some reason), the next StretchDIBits (frame n+1) can happen before the second page flip, so frame n was rendered but never displayed.

PatBlt
PageFlip /* Display black */
StretchDIBits /* Not displayed. */
...
PatBlt /* Overwrite the image that was not displayed. */
StretchDIBits
PageFlip

If you use DirectX, OpenGL or Vulkan, you can wait for vsync (that will come later in the series).

For the moment you can use DwmFlush to have some sort of vsync.

Ah I see!