4 ms·

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 th

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.

maxbond 1y ago
Perhaps the people at MDN are 10x typists, with competition-grade gaming keyboards.
mindslight 1y ago
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).
- maxbond 1y ago
  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 https://news.ycombinator.com/item?id=44822183
- kazinator 1y ago
  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.
  - mindslight 1y ago
    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.
    - kazinator 1y ago
      Yes; an assymetric algorithm was described upthread by Findecanor, in the grandparent of the comment I replied to: https://news.ycombinator.com/item?id=44822183 https://news.ycombinator.com/item?id=44822183 The state machine will report a "make" event early, and then continue to deal with the bounces to detect "break".
      - mindslight 1y ago
        Sure, but why does it feel like we're going around in circles here? Labeling that an "asymmetric algorithm" is technically correct but it implies it's some rarer special case. Whereas it's literally just the common debouncing technique, at least when I was learning embedded development ~20 years ago. And there's no reason for a keyboard to be using anything different. As I said, the real delay factor with keyboard is matrix scanning. If there is a keyboard that has 30ms of latency to register a keypress, I would guess that a ~400Hz (sqrt(104) -> 11 columns?) scanning frequency was as good as could be handled by whatever early cheap USB microcontroller they used, and its designers figured that was good enough for productivity use.
  - vrighter 1y ago
    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.
moritzwarhier 1y ago
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.
- kazinator 1y ago
  > 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.
  - moritzwarhier 1y ago
    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!)

maxbond 1y ago

Perhaps the people at MDN are 10x typists, with competition-grade gaming keyboards.

mindslight 1y ago

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).

maxbond 1y ago
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 https://news.ycombinator.com/item?id=44822183
kazinator 1y ago
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.
- mindslight 1y ago
  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.
  - kazinator 1y ago
    Yes; an assymetric algorithm was described upthread by Findecanor, in the grandparent of the comment I replied to: https://news.ycombinator.com/item?id=44822183 https://news.ycombinator.com/item?id=44822183 The state machine will report a "make" event early, and then continue to deal with the bounces to detect "break".
    - mindslight 1y ago
      Sure, but why does it feel like we're going around in circles here? Labeling that an "asymmetric algorithm" is technically correct but it implies it's some rarer special case. Whereas it's literally just the common debouncing technique, at least when I was learning embedded development ~20 years ago. And there's no reason for a keyboard to be using anything different. As I said, the real delay factor with keyboard is matrix scanning. If there is a keyboard that has 30ms of latency to register a keypress, I would guess that a ~400Hz (sqrt(104) -> 11 columns?) scanning frequency was as good as could be handled by whatever early cheap USB microcontroller they used, and its designers figured that was good enough for productivity use.
- vrighter 1y ago
  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.

moritzwarhier 1y ago

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.

kazinator 1y ago
> 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.
- moritzwarhier 1y ago
  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!)