Comment by Findecanor
7 months ago
An office keyboard's own debouncing could delay a key press 30 ms, and then the OS, software and graphics/monitor hardware would delay it just as much before the user could see the character on screen. So, indeed, 10 ms is much too low.
The delay between key press and sound starts to become noticeable at around 10ms when you play an electronic (musical) keyboard instrument.
At 20-30ms or more, it starts to make playing unpleasant (but I guess for text input it's still reasonable).
50ms+ and it starts becoming unusable or extremely unpleasant, even for low expectations.
I'm not sure how much the perception of delay and the brain lag differs between audio and visual stimuli.
But that's just about the perceived snappiness for immediate interactions like characters appearing on screen.
For events that trigger some more complex visual reaction, I'd say everything below 25ms (or more, depending on context) feels almost instant.
Above 50ms you get into the territory where you have to think about optimistic feedback.
Point that most seem to miss here is that debouncing in FE is often about asynchronous and/or heavy work, e.g. fetching search suggestions or filtering a large, visible list.
Good UIs do a lot of work to provide immediate feedback while debouncing expensive work.
A typical example: when you type and your input becomes longer with the same prefix, comboboxes don't always need to fetch, they can filter if the result set was already smallish.
If your combobox is more complex and more like a real search (and adding characters might add new results), this makes no sense – except as an optimistic update.
_Not_ debouncing expensive work can lead to jank though.
Type-ahead with an offline list of 1000+ search results can already be enough, especially when the suggestions are not just rows of text.
> 10ms when you play an electronic (musical) keyboard instrument.
Sound travels 3.4 meters in that time; if your speakers are that far away in a live situation, there is your extra 10 ms.
You are right about that, I was also wondering whether the numbers and categories I pulled.. chose make sense.
I was mainly thinking about keyboards where you have at least some close exposure to a/the sound source.
For example, organ players sure need to incorporate some intuition about the pipe sound latency into their skills (on top of the sound space and reverb!)
No, correct debouncing of a hardware button should not add any delay to a single press. It's not wait-then-act, but rather act-then-wait-to-act-again. You're probably thinking of a polling interval (often exacerbated by having key switches wired in a matrix rather than one per pin).
The bouncing behavior itself adds delay. If it takes 30 ms for the switch to settle to a state where it is considered closed according to the debouncing algorithm's parameters, then that's what it is. The algorithm might be "sample every millisecond, until 9 out of 10 samples show "closed". That imposes a minimum delay of 10 ms, and the maximum is whatever it takes for that criterion to be reached.
That's a low pass filter. And I suppose in the type of highly-resilient slow changing signals like OP mentioned in a different comment, it makes sense to do that and even to refer to it as "debouncing". But for general consumer electronic devices with basic local buttons, the standard algorithm is something more like act on the first close, then ignore the next 10 samples. When there is no other reason for a switch to read as closed, the first close means the button has definitely been pushed. The point of debouncing is to avoid seeing the open-close-open-close oscillation afterwards (contacts settling) as their own release-press combos.
2 replies →
no, when the signal first goes high, the button is immediately considered pressed. The debouncing stops it filters out several transitions after, so that the button stays pressed until the circuit has settled in the low state.
They describe that approach in another comment [1], so I take it to be a descriptive statement about low end keyboards. Perhaps the engineers designing these keyboards view 30ms as an acceptable latency to prevent spurious key presses.
[1] https://news.ycombinator.com/item?id=44822183
Perhaps the people at MDN are 10x typists, with competition-grade gaming keyboards.