Input events are occasionally skipped (regression from input handling changes in 3.3)

[saward]

---

Bugsquad edit: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version:
3.3

OS/device including version:

AMD Ryzen 3600
5700 XT
Arch Linux 5.11.16-arch1-1

Issue description:

With Godot 3.2.3, the tilemaps I'd set up performed poorly when zoomed out. Now, with 3.3, it's smooth which is great, but now it seems to be missing input events occasionally.

Most of the time using WASD to pan the camera works fine, but sometimes it keeps moving in a direction once I release key press, and sometimes it doesn't start moving immediately. Outputting the events, it looks like the key press (or key release) isn't registered. I don't recall noticing this in 3.2.3, but I did not test extensively.

Steps to reproduce:

Load and run the attached test project, full screen, zoomed out (should be by default), and try panning around with WASD. Hopefully you observe that some inputs are being skipped -- that the panning isn't always moving exactly in line with the keys you're pressing

I tested also on a Windows machine with a weaker CPU and GPU, and the issue doesn't seem to be (as) apparent.

Minimal reproduction project:

tilemap_camera.zip

[Calinou]

Can you reproduce this if you call Input.set_use_accumulated_input(false) in the main scene script's _ready() function? This disables input accumulation, which groups input events together to be batched on a per-rendered frame basis.

[saward]

I noticed I'm using _physics_process instead of _process for camera inputs. Tested these permutations:

• _phsyics_process & accumulate=default
• _physics_process & accumulated=false
• _process & accumulate=default
• _process & accumulate=false

While the problem is evident using all, it seemed a bit harder to trigger with Input.set_use_accumulated_input(false). This isn't a rigorous experiment though so it may also be making no difference.

[saward]

I should add, most of the time (most inputs) it doesn't happen, but happens often enough for me to notice.

[jusw85]

I've had a very similar issue after updating to Godot 3.3, also on Arch Linux. I fixed it by disabling vsync in Project Settings. Let me know if it helps.

[jusw85]

I have no issue with 3.2.3, only with 3.3. Also, it seems to be input in general, not tied to the camera.

Here's my reproduction project:

test.zip

Try holding down right, then repeatedly tapping left. Sometimes the input isn't registered immediately.

After adding Input.set_use_accumulated_input(false), it seems to help, but doesn't fix it entirely. Only disabling vsync solves it. This is standalone desktop executable, no issue with HTML5 export.

[Calinou]

@jusw85 Can you test this on all older 3.3 RCs and betas to determine when the regression started? You can download them here and here (3.2.4 was renamed to 3.3 during the development process).

[jusw85]

@jusw85 Can you test this on all older 3.3 RCs and betas to determine when the regression started? You can download them here and here (3.2.4 was renamed to 3.3 during the development process).

Issue appears in beta 1 Godot_v3.2.4-beta1_x11.64.zip

No issue with 3.2.2 Godot_v3.2.2-stable_x11.64.zip

[saward]

Just thought I'd mention that I've just tried 3.3.2 and the issue is still present.

[Wolfe2x7]

In my opinion the title should be changed, because I have had a frustrating time with inputs in general, like @jusw85, and I think this is all related.

Under circumstances I cannot determine, making it difficult to reproduce, Godot may ignore inputs, period. With how my project works, this sometimes causes analog-input-based values to become stuck, which is game-breaking. It may be fixed simply by closing and restarting the game. I think Godot might also be reporting duplicate "is_action_just_pressed" events, but I'm not sure yet.

I've had enough and I am going to try disabling Vsync and capping the framerate at 144 to see if it helps ("debug/settings/fps/force_fps" is not only for debug mode, is it?). If that doesn't work, I intend to try going back to Godot 3.2.2, because the symptoms are unacceptable. :|

[Calinou]

("debug/settings/fps/force_fps" is not only for debug mode, is it?)

It works in exported projects too.

Could anyone who is running into this issue try to bisect the regression down to an individual commit hash? According to @jusw85, the "good" commit is 31d0f8a (3.2.3-stable) and the "bad" commit is 2e073ec (3.2.4-beta1).

Also, for those with the issue only occuring when V-Sync is enabled, it's worth checking whether the delta smoothing PR improves the situation.

[Wolfe2x7]

It works in exported projects too.

Good to know in general, thanks.

I will spend some time with 3.2.2, 3.2.3, and 3.2.4 to see if I can corroborate @jusw85's observation.

EDIT: Easy part done; I confirmed the issue affects my project with 3.2.4 beta 1. Like 3.3.2, it seems to occur or not each time the game is started. Once it occurred, it was evident right away on my project's temporary menu (navigating with a gamepad). I went for a drive to make sure, and the steering and throttle (floats updated by Input.get_action_strength()) got stuck after a short while.

To clarify, such inputs do not become permanently stuck. But they don't always become immediately un-stuck with further input, either.

[jusw85]

bisect from 3.2.3-stable to 3.3-stable.

This is the commit which introduces the problem: f725d9c

To clarify, I'm not missing any inputs. All my inputs are registered. Instead, my (keyboard) inputs are delayed and experiencing input lag. It doesn't happen consistently. Sometimes its very noticeable, other times barely noticeable. Disabling vsync in the project fixes the issue for me. I haven't tried other inputs such as mouse clicks. I estimate the input lag to be around 100ms - 500ms (definitely <1second)

I'm using Openbox on Arch Linux with the picom compositor with vsync enabled (on the compositor)

[Wolfe2x7]

EDIT: My apologies to all, for I have to admit that I must have uncovered a hardware problem on my end. Switching from my usual PC controller to the DS4 from my PS4 has fixed my input-related issues. D'oh!

I have booted my project many times in 3.2.3 stable now, and I cannot reproduce the symptom I've reported for 3.2.4 beta 1 and 3.3.2 stable. I have also tried turning off Vsync, which does not prevent the symptom. Turning off "Always on Top" has no effect either, so I don't think it's related to #48312.

Unfortunately I still have not been able to find a clue on what circumstances are causing the problem in the first place. When it happens, sometimes it can be repeated for a period of time each time the game is restarted, while sometimes restarting the game may fix it. When it isn't happening, I can't predict how many times I could restart the game before the problem appears again.

I've tried closing other programs when it happens, and I've tried deliberately acquiring keyboard focus in another window (like right here) to make it appear. Neither works.

---

EDIT: I have found one possible clue.

While printing Input.get_action_strength() values to output, I caught the analog input freezing up, reporting a value even though I had released the analog stick. Without touching the controller, moving the game window or clicking in another is enough to wake up the input collection and return it to zero.

[pouleyKetchoupp]

For anyone who can reproduce the issue, could you please test with #49720 to see if it helps?

There's a mutex to protect multi-threaded operations for events which I've tried to switch to a spin lock to see if it can avoid some random stalling.

[jusw85]

For anyone who can reproduce the issue, could you please test with #49720 to see if it helps?

There's a mutex to protect multi-threaded operations for events which I've tried to switch to a spin lock to see if it can avoid some random stalling.

Doesn't help.

I simulated keypresses using xdotool to demonstrate the issue. It repeats right then left with 0.1s interval.

sleep 1; for i in {0..20}; do xdotool keydown Right; sleep 0.1; xdotool keyup Right; xdotool keydown Left; sleep 0.1; xdotool keyup Left; done

3.2.3

good.mp4

#49720, 3.3.*

bad.mp4

bad2.mp4

[hunterloftis]

That excellent reproduction from @jusw85 is exactly what I experience with 3.3.2 on Ubuntu Desktop.

Despite all the improvements in 3.3, reliable input is a critical component for any game, so I'll have to stick with 3.2.3 for now.

[CritCorsac]

I did some testing on this issue and I've discovered something that might be of interest when running games with v-sync enabled in Godot 3.3.

When using Linux Mint 20.2, the stated input lag issue is very noticeable and the inputs will randomly delay themselves for almost up to a full second seemingly at random intervals. Regular gameplay becomes much harder, if not totally impossible in some cases because of this.
So I tried using Debian 10.10 (non-free) and found that the issue is still present, but it is much less invasive. It only really becomes noticeable when using the terminal command provided by @jusw85 a couple of times when running on Debian.

Both distros were run on the same machine, but I think it might be best if someone else could also confirm this discrepancy between the two distros on their own computer.

[Gnumaru]

I'm using godot 3.3.3 on ubuntu 21.04 X64 and I have both the default gnome environment and LXDE (openbox) installed.

Interestingly with me the vsync workaround is the oposite: when vsync is turned off I get the input delay, while with vsync turned on input works without problems. This happens both on gdm with xorg (gnome) and openbox with xorg (lxde). I havent tested with wayland. Input.set_use_accumulated_input(false) doesn't seem to make any difference.

I'm testing only keyboard input and I would like to notice that the problem seems to happen most commonly on the keyup events. The keydown events doesnt seem to have any problem, but the keyup events several times have a big delay of about one second between the actual mechanical release of the key and the engine noticing it.

The bug can be tested creating an empty scene, attaching the following script and running it on the editor:

extends Node
func _input(event):
	print(event.as_text())
func _physics_process(delta):
	print(Input.is_action_pressed('ui_right'))

While the scene is running, keep your eyes on the console (preferably a dedicated terminal window, not the built-in console) and do very quick key taps of the 'right arrow' key with a small interval of about half second between each keypress. One will note that sometimes the keydown and keyup events happen right after one other or with a very few number of frames between. But sometimes, the keyup will delayed by a large amount, like one second.

[pouleyKetchoupp]

Thanks for all the feedback and test scripts, it's going to be very useful! I'm sorry I didn't look into this issue in the past couple months, but I'll try to find some time soon to see if I can figure out what's going on.

[YaroslavLisovets]

I've recently faced the same problem. In my case it happens only when gamepad is connected. Otherwise I don't face this problem. And v-sync has nothing to do for me.
godot 3.3.2 windows 11

[Gnumaru]

In my case it happens only when gamepad is connected. Otherwise I don't face this problem

Do you mean that, when a gamepad is connected, the problem occurs with gamepad input only? or with any other kind of toggle (non axis) input? like if you connect the gamepad and start experiencing the problem also on keyboard input?

[hunterloftis]

I've recently faced the same problem. In my case it happens only when gamepad is connected. Otherwise I don't face this problem. And v-sync has nothing to do for me.
godot 3.3.2 windows 11

Given that it's a different input altogether, vsync doesn't impact it, and it's on a wholly different operating system, I would be surprised if this were indeed the same issue.

[pouleyKetchoupp]

@jusw85 I'm able to reproduce the issue using your script, but for me it happens in both 3.2.3 and 3.3.2 whether vsync is on or off. I'm on ArchLinux / Gnome.
Is it always perfect on 3.2.3 like in the video for you, or do you experience similar issues, just more consistently in 3.3.2? Does it happen in 3.2.3 under any circumstances?

[jusw85]

@pouleyKetchoupp

I tested again using 3.2.3 from here and 3.3 from here. I'm on Arch / Openbox + picom (vsync on)

On 3.3, the issue almost always occurs (with vsync on). Sometimes it's less noticeable, sometimes more. This is one of the more noticeable ones. Note the occasional responsiveness issues with the input.

out.mp4

On 3.2.3, I don't notice any problems. However, because I added a marker for the midpoint, I observed that sometimes it drifts away from the start (although sometimes it returns exactly to the start). This however might be due to timing precision in sleep 0.1 and having an extra frame of right down or 1 frame delay of right up.

out2.mp4

[eerbin13]

Using v3.3.3 stable, just encountered this bug as well. It was definitely due to a controller being plugged in. I had a PS4 controller plugged in, and the arrow keys would not report correctly when being held down.

[cybereality]

I've created a sample project to reproduce this easily. I also attached a modified version of @jusw85 's script. Basically it makes the sprite oscillate left and right in front of a line. With V-Sync disabled, the test is perfect, the sprite will end exactly in the same spot as beginning, I've tested this all day and it's perfect to the pixel (meaning I don't think there is any problem with the sync between the bash script sleeping and Godot). However, if you enable V-Sync in the Godot project, the results are very far off. Sometimes the sprite moves as far as 300 pixels away from the center line or even completely off-screen. I have noticed that if you disable V-Sync, but force FPS in Godot to your refresh rate, the problem still goes away. Please let me know if there is anything else I can do to assist in fixing this. Thanks.

V Sync Off
https://user-images.githubusercontent.com/3398643/136680961-dd7f1b0c-0585-45bc-b047-009f7bafe0b3.mp4

V Sync On
https://user-images.githubusercontent.com/3398643/136680965-2886ecc6-2167-4f35-aab5-51609ab6ea81.mp4

InputTest.zip
left-right.zip

[pouleyKetchoupp]

Thanks for the extra information! And sorry for the lack of update on this issue, it's hard to find time to investigate with the other things I've been focusing on.

@Rubonnek or other contributors, you're very welcome to investigate if you're interested. Let me know if you need pointers and please share whatever you find :)

[pouleyKetchoupp]

I think I've finally found a fix for this issue, so if anybody can check on a local build please confirm that #54313 solves the problem for you.

---

I was able to reproduce the issue on 3.3.2 and on 3.4 based on @jusw85's and @cybereality's tests.
I noticed there's a little bit of random delay on 3.2.3 as well, but not as visible, which makes comparative tests difficult to assess in some cases.

I've made a modified version of @cybereality's project that shows more in details how much the object is moving left and right to spot discrepancies more accurately:
InputTest2.zip

[akien-mga]

Fixed for 4.0 by #54326.

Will be fixed in 3.5 by #54313, and cherry-picked for 3.4.1 (too late for 3.4).
Edit: Changed my mind, it was merged for 3.4 RC 3 in the end.

[cybereality]

I can confirm that @pouleyKetchoupp's patch does indeed fix the problem on my system.

Thanks a bunch for your hard work. This was a pretty nasty bug.

[akien-mga]

Fixed for 3.4 by #54313.