Fix: Windows not redrawing when requested

[Klemen2]

related to: #595

Tested on windows 10 and 11

Digging into windows documentation WM_PAINT, that winit is using to sent redraw requests, is only sent by the system or when another application makes a request to paint a portion of an application's window (https://learn.microsoft.com/en-us/windows/win32/gdi/wm-paint) and that it will only be sent when there are no messages in the queue.

With this fix constantly updating transforms work, this is 5000 elements while recording being smoother than 200 before.

windows.mp4

WPT results

No changes in test results compared to main.

_{Generated by the WPT workflow.}

[nicoburns]

Hmm... seems like this should be opt-in at least. This will presumably completely remove any notion of "frame pacing" (even to the limited extent that Winit supports it)? We should perhaps ask around other Rust GUI communities to see how they solve this, because it doesn't seem Blitz-specific.

[Klemen2]

I created an issue on winit and it is technically a 2 years old bug, in the meantime I can put it behind a feature instead if that is preferred. Something like "windows-immediate-redraw" or something like that? and change it so that it is deduped automatically and then redrawn in the event loop before? after? event handeling
We could also limit tickrate somehow, but it would not fix this issue 100%

[nicoburns]

Yeah, something like that makes sense I think

[Klemen2]

I chose redrawing after new event to avoid another variable for double redraws as WindowEvent::RedrawRequested may be sent if message queue is empty instead

[Klemen2]

I removed the feature flag and instead went with coalescing, I believe this is a better approach