rust-windowing / rust-windowing/winit

Key repeat event has very high input lag on Windows

Open
#4,043 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

B - bug DS - win32
Dominant language
Rust
Stars
6.2k
Forks
1.3k
Avg merge
2d 19h
Merged PRs (30d)
9

Description

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 - https://github.com/rust-windowing/winit/issues/2127

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the minimal Rust reproduction using Winit v0.29.3, EventLoop::run_on_demand, ControlFlow::Poll, and the KeyboardInput handler described in the issue. Compare the timing and delivery of repeated key events and the RedrawRequested input buffer, including the behavior noted in issue #2127; done means identifying and reproducing the lag or lost events with a verified event-loop behavior change.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.