bevy icon indicating copy to clipboard operation
bevy copied to clipboard

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

Open geirsagberg opened this issue 3 years ago • 5 comments

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 https://github.com/bevyengine/bevy/issues/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 avatar Sep 07 '22 19:09 geirsagberg

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 avatar Sep 07 '22 19:09 geirsagberg

Found this related issue from winit: https://github.com/rust-windowing/winit/issues/310

geirsagberg avatar Sep 07 '22 19:09 geirsagberg

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

geirsagberg avatar Sep 07 '22 21:09 geirsagberg

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

geirsagberg avatar Sep 08 '22 14:09 geirsagberg

I suspect this is the same problem as in https://github.com/bevyengine/bevy/issues/4664

geirsagberg avatar Sep 08 '22 21:09 geirsagberg

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

senicko avatar Oct 02 '22 13:10 senicko

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?

jeffparsons avatar Nov 19 '22 00:11 jeffparsons

Consolidating with #5984.

alice-i-cecile avatar Feb 14 '23 13:02 alice-i-cecile