4 ms·

I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "impercepti

by sgt 3y ago

I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.

hnlmorg 3y ago
what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.
- sgt 3y ago
  The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.
  - noergl 3y ago
    Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie). Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today. Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.

by sgt 3y ago

hnlmorg 3y ago

what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.

sgt 3y ago
The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.
- noergl 3y ago
  Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie). Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today. Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.