Isn't it carry over from anti-chattering/de-bouncing feature?
Most micro-processors has useful edge- and level-detect interrupt features that allows instant unconditional jump to interrupt handling subroutine(think callback functions) often used for physical buttons handling.
And one of common knowledge associated with that is, physical buttons tend to go through a transitional random state while being pressed, generating rapid succession of false on-off signals. This could trigger the interrupt detection feature, and while there will be little chances of memory leaks and no GC mess from this at all thanks to interrupt systems being static objects, it could still put system in a weird state and/or massively slow it down.
The most typical solution to button chattering problem is as follows:
1. have the button input pin triggered for rising edge(button not pressed to pressed).
2. upon detection, immediately disable interrupt upon trigger, optionally send button down event to OS.
3. wait a millisecond, or for whatever duration the button takes to settle.
4. while at it, re-trigger the interrupt now for falling edge to detect button release.
5. on falling edge, pass the button up and button click events to the OS, or call the onClick() callback, and configure everything back to 1.
(0. call the hardware guy cubicle for further discussions)
... which results in classic MacOS style behavior of button press greying the button without action, and that is cute.
But the point is, it's less of a UX feature, more of hardware quirk suppression. Certainly a VR keyboard button virtually pressed by 3D spatial location of individual fingers don't require such pieces of anti-chattering code.
[expletive], I'm bad at drawing conclusions. Maybe I could say, by Chesterton's Fence principle, here the theory of Act on Release implementation is explained, and removal of fence can now be freely discussed.
Debounce makes act on release a lot harder than act on press. If you want act on release with a bouncy switch you have to actually act on N number of milliseconds of switch open to ensure that it's an actual release and not a bounce.
Act on press is simply just rising edge and then suppress for N milliseconds.
Most micro-processors has useful edge- and level-detect interrupt features that allows instant unconditional jump to interrupt handling subroutine(think callback functions) often used for physical buttons handling.
And one of common knowledge associated with that is, physical buttons tend to go through a transitional random state while being pressed, generating rapid succession of false on-off signals. This could trigger the interrupt detection feature, and while there will be little chances of memory leaks and no GC mess from this at all thanks to interrupt systems being static objects, it could still put system in a weird state and/or massively slow it down.
The most typical solution to button chattering problem is as follows:
... which results in classic MacOS style behavior of button press greying the button without action, and that is cute.But the point is, it's less of a UX feature, more of hardware quirk suppression. Certainly a VR keyboard button virtually pressed by 3D spatial location of individual fingers don't require such pieces of anti-chattering code.
[expletive], I'm bad at drawing conclusions. Maybe I could say, by Chesterton's Fence principle, here the theory of Act on Release implementation is explained, and removal of fence can now be freely discussed.