Add a throttling setting to button/key (not axis) inputs

[geekley]

The Problem

I have set ui_* input actions to both keyboard and gamepad main axis as well as d-pad buttons:

See image: Input map settings

I noticed I'm having a controller-specific bouncing issue e.g. when navigating the UI focus through d-pad buttons.
Analog works fine, but D-pad works in one controller but another has bouncing - it moves twice. The d-pad on this controller (it's actually a generic-brand GameCube adapter) sends both button inputs and 7th/8th axes, but as you see these axes aren't assigned, so it can't be this. It seems to be a bouncing issue.

I always get 2 inputs consistently, it's not random. Delay in my case seems to be about 1ms or less:

Example output of prints(direction, Time.get_ticks_usec()) when alternating left/right and up/down

1 4261610
1 4261997
-1 6523895
-1 6524350
1 8854282
1 8854464
-1 9233236
-1 9233781
1 10146373
1 10147144
-1 10328562
-1 10329311
1 11720107
1 11721085
-1 11926300
-1 11926625
1 12496478
1 12497132
-1 12661626
-1 12662060
1 13040523
1 13041212
-1 13195519
-1 13195698
1 14034216
1 14035128
-1 14166677
-1 14167121

Why not a GDScript solution?

While I could try to implement a throttling scripting solution for specific code handling input, it wouldn't help with things like the inbuilt way of navigating the UI focus through buttons. Unless there is a way I'm unaware of to intercept every input event and de-duplicate it in a way that affects native UI controls as well?

In any case, even if I can do it though some Autoload node, this is generic enough that all projects would benefit from it, so I think it should be in core, handled at a more low-level code in the engine.

Proposed Solution

I'm aware of #11267, but this is different; I'd like a throttling solution on the input level.
For example, it could be implemented as:

1. a global setting that applies to all input from buttons/keys/clicks/touch (but not axes); and/or
2. a per-action new column "Throttle" similar to "Deadzone"
3. an API to set it per-device in script, applies to buttons/keys/clicks/touch (but not axes) of that device only

In either case you would set the amount of milliseconds or microseconds to ignore repeated input. And (1) and (2) should be configurable from script too, of course, so games can have UI for it if desired.

I'd suggest some sensible non-zero default for it of a humanly impossible low value (e.g. 5000μs = 5ms seems fine?), so it doesn't impact games much. Or if the per-action default is zero, there should be at least a global minimum setting as well.

---

EDIT: Btw, I'm not even sure "bouncing" is the proper term here, as I'm not even getting release events between both presses:

12373424 InputEventJoypadButton: button_index=11, pressed=true, pressure=0.00
12374005 InputEventJoypadButton: button_index=11, pressed=true, pressure=0.00
12515147 InputEventJoypadButton: button_index=11, pressed=false, pressure=0.00
12515569 InputEventJoypadButton: button_index=11, pressed=false, pressure=0.00
12643918 InputEventJoypadButton: button_index=12, pressed=true, pressure=0.00
12644385 InputEventJoypadButton: button_index=12, pressed=true, pressure=0.00
12806540 InputEventJoypadButton: button_index=12, pressed=false, pressure=0.00
12807152 InputEventJoypadButton: button_index=12, pressed=false, pressure=0.00
12900272 InputEventJoypadButton: button_index=11, pressed=true, pressure=0.00
12901203 InputEventJoypadButton: button_index=11, pressed=true, pressure=0.00
13093268 InputEventJoypadButton: button_index=11, pressed=false, pressure=0.00
13093553 InputEventJoypadButton: button_index=11, pressed=false, pressure=0.00
13216062 InputEventJoypadButton: button_index=12, pressed=true, pressure=0.00
13216849 InputEventJoypadButton: button_index=12, pressed=true, pressure=0.00
13399838 InputEventJoypadButton: button_index=12, pressed=false, pressure=0.00
13400384 InputEventJoypadButton: button_index=12, pressed=false, pressure=0.00

Bouncing/throttling intervals aside, it's already weird that a controller button can at all send 2 identical non-echo consecutive press events without requiring a release event in-between (and 2 release without a press in-between). So another option is blocking those repeated ones that don't change "state" anyway even without a setting, at least for short repeated intervals of exact duplicate button actions.

---

I'm opening this as discussion, sorry if it should've been an issue instead.

[Calinou]

I'd suggest some sensible non-zero default for it of a humanly impossible low value (e.g. 5000μs = 5ms seems fine?), so it doesn't impact games much. Or if the per-action default is zero, there should be at least a global minimum setting as well.

5 ms is non-negligible for many types of games (that's almost 1/3rd of a frame at 60 FPS), so I'd prefer not. Input lag in modern games is high enough as it is 🙁

However, for this use case, wouldn't throttling instead of debouncing resolve the issue? With throttling, you acknowledge the first input but discard the second one that occurs at nearly the same time. A throttle interval of 5 ms is perfectly acceptable here, as humans can only press buttons so many times in a second. (This wouldn't affect anyone unless they manage to press a button 200 times a second, which is completely impossible.)

[geekley]

Yeah, this is what I meant. I didn't know the exact difference:

I'm not even sure "bouncing" is the proper term here, as I'm not even getting release events between both presses

What I meant is process the first input and be "insensitive" to repetition of that same input for a while, no need to delay it. I guess I was using the wrong term then, I'll update it.

[geekley]

And to clarify my EDIT at the bottom of the post.

At first I thought I was getting a bouncing of type press->release->press in a single press, which you could also want to solve for very small intervals (specially an issue in clicks on an old mouse), but it can't be too big so as to not affect behavior - this solution would ignore the release events too.

But turns out it's doing just press->press, which should be safer to solve even for larger intervals, as those button events are identical and as such should be safe to de-duplicate through throttling.