windows: event delivery with public_window_callback and thread_event_target_callback

[tronical]

Hi!

We're seeing what looks like a bug in winit on windows (slint-ui/slint#418). Before I file a ticket I thought I'd ask here first to get a better understanding how the winit internals, in hope of creating a standalone test case or perhaps even a patch.

On a high-level the issue we're seeing is that sometimes when we issue a window.request_redraw() call, the corresponding Events::RedrawRequested is never sent to the event loop callback in the application.

I noticed that the call to winuser::RedrawWindow() succeeds (returns true). The corresponding WM_PAINT however is only received by thread_event_target_callback, not by public_window_callback. AFAICS only the latter dispatches Events::RedrawRequested.

I'm curious, what is the distinction between the two window procedures?

[maroider]

I don't fully understand the details of the implementation, but the rationale for the current behaviour is given in this comment.

[tronical]

Thanks, that helps a bit to understand the reason behind flush_paint_messages. And I guess the assert in thread_event_target_callback on the result of calling flush_paint_messages ensures that there are no further paint messages are pending - as we are already processing one. That assert does not trigger. What it doesn't explain though is why WM_PAINT is not received by public_window_callback though. I wonder if it should?

Do you know who else might know this code?

[maroider]

Do you know who else might know this code?

I believe @Osspial is the one who wrote it, but they're not really that active these days.

[tronical]

It turns out that this issue was caused by us not reacting to MainEventsCleared, etc. not correctly (not returning the right control flow value). So this discussion can be closed :-)