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

Inputs are not processed correctly if key repeat rate is faster than FPS #5909

Closed
geirsagberg opened this issue Sep 7, 2022 · 8 comments
Closed
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior

Comments

@geirsagberg
Copy link

geirsagberg commented Sep 7, 2022

Bevy version

0.8.1

[Optional] Relevant system information

Mac OS Monterey 12.5.1

`AdapterInfo { name: "AMD Radeon Pro 5500M", vendor: 0, device: 0, device_type: DiscreteGpu, backend: Metal }`

What you did

I have my key repeat rate set faster than normal, by following this StackOverflow thread, specifically:

defaults write -g KeyRepeat -int 1 # normal minimum is 2 (30 ms)

What went wrong

When I am running any Bevy game where FPS is locked (via PresentMode::Fifo or VsyncAuto), input seems to buffer up, so that when I release e.g. the arrow key, the character keeps moving for several seconds.

If I change the KeyRepeat back:

defaults write -g KeyRepeat -int 2

Then this does not happen (although there is still a tiny bit of lag, see #3317)

Additional information

When I set PresentMode::Immediate it mostly works as expected, although some times the FPS is still locked to screen refresh rate, though that is a separate issue (And in these cases, the exact same problem as described above is present).

@geirsagberg geirsagberg added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Sep 7, 2022
@geirsagberg
Copy link
Author

I have a feeling this is related to winit, but I don't know enough about the underlying dependency to know if it needs to be fixed there, or if it can be fixed somehow in Bevy.

@geirsagberg
Copy link
Author

Found this related issue from winit: rust-windowing/winit#310

@alice-i-cecile alice-i-cecile added A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in and removed S-Needs-Triage This issue needs to be labelled labels Sep 7, 2022
@geirsagberg
Copy link
Author

geirsagberg commented Sep 7, 2022

Someone else had the same problem with winit and switched to using DeviceEvent instead of WindowEvent: https://gitlab.com/veloren/veloren/-/merge_requests/3165
Which again seems to have led to a PR in winit: rust-windowing/winit#2182

@geirsagberg
Copy link
Author

Maybe something like https://github.com/rukai/winit_input_helper could be used?

@geirsagberg
Copy link
Author

I suspect this is the same problem as in #4664

@senicko
Copy link

senicko commented Oct 2, 2022

Are there any updates on that? I am experiencing a simillar problem and would like to fix it somehow.

@jeffparsons
Copy link

I've just started tinkering on a new project using Bevy and I've immediately run into significant input lag. It seems there are enough related issues with different root causes that I'll probably end up trying a bunch of different things that people have suggested in issues here to discover which issue or issues are the ones affecting me.

That's okay. I can do that.

However...

It feels like input lag in general is likely to be an ongoing issue for a lot of other people, too, so I can't help but think it might be worth putting together some kind of diagnostic tool to help people quickly and precisely understand what's going on in their case. I'm imagining something that can take measurements by itself rather than having to rely solely on user-perceived lag. To do this meaningfully I'm imagining things like:

  • Automatically turn on and off vsync
  • Automatically adjust system key repeat rate
  • Somehow collect and timestamp input events from somewhere lower in the stack to compare with when they get processed by Bevy; even if they can't be married up live, you could maybe correlate them retrospectively?
  • Synthesise input events somewhere lower in the stack as a way of narrowing down the source of the lag?

I don't know how much of this is possible. I guess I have some reading to do. Is anybody already working on something like this?

@alice-i-cecile
Copy link
Member

Consolidating with #5984.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Input Player input via keyboard, mouse, gamepad, and more A-Windowing Platform-agnostic interface layer to run your app in C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

No branches or pull requests

4 participants