Calling `Window.redraw_window()` can cause the window to seemingly "destroy and recreate" itself intermittently on Windows 10

[maroider]

If my program calls redraw_window() inside the MainEventsCleared event and I hold my mouse still and don't use my keyboard, the window's decorations will briefly light up as if hovered over and then go back to normal. This happens intermittently. The window's task bar icon will also disappear and reappear at the same time the window decorations blink.

Here is a video demonstrating the bug.
The following is the code used in the video:

use winit::{
    event::{DeviceEvent, ElementState, Event, KeyboardInput, VirtualKeyCode, WindowEvent},
    event_loop::{ControlFlow, EventLoop},
    window::WindowBuilder,
};

fn main() {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new()
        .with_title("A Buggy Window")
        .build(&event_loop)
        .unwrap();
    let mut bug = false;
    event_loop.run(move |event, _, control_flow| match event {
        Event::WindowEvent {
            event: WindowEvent::CloseRequested,
            ..
        } => *control_flow = ControlFlow::Exit,
        Event::DeviceEvent {
            event:
                DeviceEvent::Key(KeyboardInput {
                    virtual_keycode: Some(VirtualKeyCode::B),
                    state: ElementState::Pressed,
                    ..
                }),
            ..
        } => {
            bug = !bug;
            if bug {
                println!("bug enabled");
            } else {
                println!("bug disabled");
            }
        }
        Event::MainEventsCleared => {
            if bug {
                window.request_redraw();
            }
        }
        _ => {}
    })
}

I've managed to get the bug to appear on both winit = 0.21.0 and on the master branch (9999f53).

[filnet]

We have pushed a number of critical fixes for Windows.
Please retest on master.

[maroider]

The issue persists as of e85a80d. I couldn't reproduce the issue with the window focused, but I had the same issue with 9999f53. It seems like the blinking is dependent upon some unknown outside factor.

[filnet]

I have reproduced a similar issue.
Every ~5 seconds the title bar briefly flashes the (Not responding) and the X button highlights.

Could be related to this : https://superuser.com/questions/961843/how-does-windows-know-if-a-program-is-not-responding/961910

[maroider]

It feels strange to me that that would be the root cause, but I have no idea how winit's back-end polls the window's event queue, so I can't say anything definitive. I might do some more detective work this week if time permits.

[filnet]

Yes, it is strange as we do call PeekMessage for every event loop iteration in Poll mode.
But it really looks like Windows is considering that the app is hung.

At first I though it could be caused by the event loop running at full speed but adding a sleep to throttle it does not remove the issue.

Poll mode calls only PeekMessage while the other modes will call GetMessage or MsgWaitForMultipleObjectsEx.
But we are calling PeekMessage with a null HWND. Could that be the cause ?

[filnet]

And I can't reproduce it on Windows 7.

[filnet]

Random related (or not) resources:

• https://docs.microsoft.com/en-us/windows/win32/win7appqual/preventing-hangs-in-windows-applications
• https://docs.microsoft.com/fr-fr/windows/win32/api/winuser/nf-winuser-disableprocesswindowsghosting?redirectedfrom=MSDN
• https://docs.microsoft.com/fr-fr/windows/win32/api/winuser/nf-winuser-ishungappwindow?redirectedfrom=MSDN

[filnet]

On Windows 10, the Task manager will show that the application is "not responding" when not moving the mouse or triggering any kind of event.

@maroider can you confirm the same ?

Edit: and this happens in Poll mode and only if request_redraw is called.

[Osspial]

I tested this on my machine and it looks like #1496 fixes this issue.

[maroider]

@filnet I haven't observed any "not responding" warnings in either the window's title bar or task manager.

@Osspial I ran the bug-inducing code against your PR and let it sit for a couple of minutes. I could not observe the bug. It does indeed seem like #1496 inadvertently fixes it.

[filnet]

I was not able to reproduce the issue with #1496