Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key repeat event has very high input lag on Windows #4043

Open
arialpew opened this issue Dec 16, 2024 · 0 comments
Open

Key repeat event has very high input lag on Windows #4043

arialpew opened this issue Dec 16, 2024 · 0 comments
Labels
B - bug Dang, that shouldn't have happened DS - windows

Comments

@arialpew
Copy link

arialpew commented Dec 16, 2024

With Winit v0.29.3 and Windows 11 24H2 build 26100.2605, the key repeat event is slow to be dispatched.

While running a game at 60 FPS, I can see between 20 and 30 frames lag between the keypress event and the keydown event (a keydown event is a pressed event with repeat = true).

A simple reproduction would be :

  • Create a Rust program with Winit v0.29.3.
  • Create an event loop.
  • Inside the callback of EventLoop::run_on_demand, match against key event and print a message. Set control flow to ControlFlow::Pool with EventLoopWindow::set_control_flow, to immediately begin new iteration.
  • Run the program and press a key but don't release it. You'll see how laggy it is for the second event to pop-in (state = Pressed, repeat = true), while the first event is near instant (state = Pressed, repeat = false). Releasing the key (state = Release, repeat = false) is also instant.
Event::WindowEvent {
    event:
        WindowEvent::KeyboardInput {
            event:
                KeyEvent {
                    state,
                    logical_key,
                    repeat,
                    ..
                },
            ..
        },
    ..
} => {
  println!("Event !");
}

The expected behavior is to get near instant feedback for all of theses events.

Edit : Also, some events are lost while the key is still being hold. To see this in practice, you buffer all the inputs and print the whole buffer inside Event::WindowEvent { event: WindowEvent::RedrawRequested, .. }, and then clear the buffer. Don't forget to add a redraw request inside Event::AboutToWait.

You'll see that some frame have empty input buffer even when the key is hold. I would expect the buffer to be refill between each RedrawRequested since the key is hold, but maybe I'm misunderstandingsome how it should be scheduled.

My setup involve Vulkan, FIFO/MAILBOX and triple buffering. I hope this isn't related because it's not that easy to debug tbh.

I don't know if v0.30 fix this, I'll test later.

Note : probably related, hard to say. The issue surface on both FIFO/MAILBOX on my app - #2127

@madsmtm madsmtm added B - bug Dang, that shouldn't have happened DS - windows labels Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B - bug Dang, that shouldn't have happened DS - windows
Development

No branches or pull requests

2 participants