Fix a pause in the event loop when clicking the title bar on windows

[aloucks]

When clicking the title bar on Windows, to drag the window, there is a noticeable ~500ms pause in continuous redraw requests. This was fixed in #839 and then regressed in #1852. The cursor blinks in both cases and is unrelated. The regression made the blink happen after the pause instead of immediately.

• Tested on all platforms changed
• Added an entry to the changelog module if knowledge of this change could be valuable to users

[madsmtm]

Will this fix #1885 too?

[aloucks]

Will this fix #1885 too?

Yes

[madsmtm]

So, I would quite like to get this fix in, as I believe it's desired by Bevy people, but we don't really have a Windows maintainer at the moment, and I don't feel like I understand enough of what's going on here myself to confidently merge this.

Maybe you could expand on why the PostMessageW is necessary in the first place (why is the default handler not sufficient?), why passing lparam = 0 is correct, and if you know, how we'd go about fixing the blinking then? Ideally as code-comments with links to official docs, makes it easier to track in the future.

Also CC author of #1852 @Ssaely

[aloucks]

So, I would quite like to get this fix in, as I believe it's desired by Bevy people, but we don't really have a Windows maintainer at the moment, and I don't feel like I understand enough of what's going on here myself to confidently merge this.

Maybe you could expand on why the PostMessageW is necessary in the first place (why is the default handler not sufficient?), why passing lparam = 0 is correct, and if you know, how we'd go about fixing the blinking then? Ideally as code-comments with links to official docs, makes it easier to track in the future.

Also CC author of #1852 @Ssaely

To be honest, I fixed this 6 years ago and I don't really remember the details. I noticed it had regressed while exploring something else. The blinking happens even when the entire WM_NCLBUTTONDOWN event handler is commented out. The primary difference is that with the change, it blinks immediately instead of after the short pause.

The short pause is ingrained in how Windows works. If you start dragging the window immediately when you click, you won't notice a pause.

I think what's happening is that the dummy WM_MOUSEMOVE is received in the system modal event loop and simulates a window drag, which cancels the pause. This would explain why the application never sees the dummy event.

I'm completely speculating here, but I'm guessing that windows is computing a delta to determine drag status and (0, 0) is always going to be far enough away that the simulated bogus drag cancels the pause. The coordinates are encoded into the lo/high bits of the lparam value.

What I can't wrap my head around is that the lparam from WM_NCLBUTTONDOWN shouldn't even be valid for the WM_MOUSEMOVE event. The lparam value of WM_MOUSEMOVE is the (x, y) coordinates of the client area, where as the WM_NCLBUTTONDOWN lparam is the (x, y) in screen coordinates. I really don't know why passing in the lparam from WM_NCLBUTTONDOWN doesn't also cancel the pause. I tested other lparam values for the dummy event with mixed results. Passing in !lparam would cancel the pause, where as a value that was only marginally different would not cancel it. (e.g. lparam + 1).

In summary, this is absolutely a hacky work-around :)

The actual robust and generally accepted solution is to execute your simulation and rendering logic from a different thread.

[madsmtm]

Thanks a lot for the context! I'd be okay with merging this if you included basically the block of text you wrote here as a code comment.