Windows not sending WindowEvent::RedrawRequested when request_redraw is called

[Klemen2]

Description

This is most likely related to #3648
As far as I can tell RedrawRequest is only sent here

winit/winit-win32/src/event_loop.rs

Lines 1304 to 1313 in 93045a5

	WM_PAINT => {
	userdata.window_state_lock().redraw_requested =
	userdata.event_loop_runner.should_buffer();
	// We'll buffer only in response to `UpdateWindow`, if win32 decides to redraw the
	// window outside the normal flow of the event loop. This way mark event as handled
	// and request a normal redraw with `RedrawWindow`.
	if !userdata.event_loop_runner.should_buffer() {
	userdata.send_window_event(window, WindowEvent::RedrawRequested);
	}

Digging into windows documentation WM_PAINT 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 application's message queue.

So when you are for example actively moving the mouse in the window and you are requesting a redraw after each event and this redraw is not quick enough, RedrawRequest will not be sent as next event like on other platforms and will wait until you either slow down or stop as the message queue fills up in between. This could be seen in: DioxusLabs/blitz#595 where redrawing at 300+ fps isn't fast enough for the message queue to stay empty for WM_PAINT to happen.

#4653 that apparently fixes #3648 does not fix this issue

Windows version

Microsoft Windows [Version 10.0.26200.8875]

Winit version

0.31.0-beta.2

[Niketion]

@Klemen2
Thanks for reporting this. I believe this is a different starvation path from the one addressed by #4653.

#4653 fixes the multi-window case where a RedrawRequested interrupts message dispatch and the next event-loop iteration emits another AboutToWait before the remaining pending paints are processed.

In this case, it appears that WM_PAINT is not generated in the first place while the Win32 message queue remains continuously populated. Since no RedrawRequested is dispatched, the interrupt_msg_dispatch logic changed by #4653 is never reached.

Could you confirm whether you tested commit bcc3130e2f9cca50b0fb8bbff706e1a6008df7de directly? The version listed in the issue is 0.31.0-beta.2, which does not contain the open PR.

Either way, I agree that #4653 does not change the request_redraw/WM_PAINT scheduling behavior and is therefore not expected to address continuous-input starvation.

[Klemen2]

Yes I did test that commit directly. I only mentioned #4653 since its set to close #3648 which in the comments mentions problems with relying on WM_PAINT for redraw requests, and since this is basically the same problem but cannot be fixed without changing more of the logic, I mentioned that it doesn't fix this problem as well so it wouldn't be closed as duplicate.
Since I'm not familiar with windows api I cannot really comment on how to fix this issue, I did found https://stackoverflow.com/questions/2325894/difference-between-invalidaterect-and-redrawwindow that said to call UpdateWindow after RedrawWindow but that doesn't seem to fix the issue either so I'll leave this for someone more knowledgeable to fix it.