Typometer: A tool to measure and analyze the visual latency of text editors
1–10 of 104 posts
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#2The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares.
It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger developers - have never seen how fast things can be, but are instead constantly subjected to delays in using applications to the extent that they think it is an absolutely normal speed[1], and then propagate that notion to the software they themselves create.
Also related: https://danluu.com/input-lag/
[1] For example, everything that uses UWP in Windows. Someone who had only ever used the Settings app in Windows 10, or (even worse) the Calculator, might not realise how absurdly slow they are in comparison to the previous versions' where they would open nearly instantaneously.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#3The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
Direct link to the section with Windows results: https://pavelfatin.com/typing-with-pleasure/#windows
Scroll a bit down for Windows with power saving, Linux (section 3.4), and VirtualBox (3.5).
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#4The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
The worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#5The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
I actually don't think that developers who use things like VSCode are simply naive. Personally, I am a young person and I frequently do use vim in a low-latency terminal emulator (xterm, mlterm) without a compositor. Yes, I enjoy the fact that it is very fast. However, I still use VSCode when I'm making more complicated edits primarily because of the plugin ecosystem. Plugins "just work", are easy to configure, and all work together nicely. I get rich syntax highlighting and intellisense. I might be doing something wrong, but this was not the experience I have had with vim.
I like the UI simplicity of VSCode in contrast to native editors such as IntelliJ and Visual Studio, which I do use when I really need the features. I am interested in efforts like Onivim 2, which seek to combine these advantages.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#6The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
Plus the new generation is pampered with much cheaper resources (RAM and CPU), so programming efficiency goes out of the window.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#7> Because sampling rate is fast enough to misinterpret contact bounce as keystrokes, keyboard control processor perform so-called debouncing of the signals by aggregating them across time to produce reliable output. Such a filtering introduces additional delay, which varies depending on microcontroller firmware. As manufacturers generally don’t disclose their firmware internals, let’s consider typical debouncing algorithms and assume that filtering adds ~7 ms delay, so that maximum total “debounce time” is about 12 ms, and average total debounce time is ~8.5 ms.
Debouncing in software is one of those things that 99 % of developers get wrong, and is something even hardware manufacturers get wrong all the time.
A lot of hardware debounces in a dumb and naive way: On the first state change, it waits 5-10 ms and sample the switch again to figure out if it was pressed or not. So you get an inherent "debounce" delay, which is entirely unnecessary.
Debouncing keys correctly works so: If the switch generates an edge, sent key down/up event immediately and ignore further switch transitions for 5-10 ms. There is no point in waiting for the switch to surely have finished bouncing before reporting the event, because if it is bouncing it MUST have been pressed/released and you know which one it is because you know the prior state of the switch.
---
Compositor delay due to VSync
Obviously compositors are using double-buffered vsync precisely because they intend to limit FPS to $smallValue in order to save power and prevent the 3D hardware from entering a high performance power state. They really should be using triple-buffered vsync, but only start to render if something changed, resulting in much lower latency without constantly running at 1000 FPS. There should be a way for the compositor to be notified of changes in client areas, since stuff like X11 damage protocol and RDP are a thing.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#8The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
The worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
Gui Emacs via tramp+ssh is awesome.
Terminal Emacs over ssh is, well, just like anything else in a terminal over ssh. Can't say I notice the latency unless the datacenter is on the other side of the country.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#9The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
The worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
idk, vim across ssh (rn from my place in the west coast to a vps in iirc the east coast) feels a lot snappier and less frustrating than my typical interaction with slack.
Re: Typometer: A tool to measure and analyze the visual latency of text editors
#10The companion article at https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger devel…
I also can't be the only one annoyed by the input lag in the windows login screen and start menu search. Somehow both of them seem to think it's fine to just ignore keypresses for half a second before doing anything.
Annoyance aside I seriously worry about the accessibility of the windows lock screen. Through a weird display setup I sometimes find myself trying to log in blind and I just can't do it. There seems to be no way to reliably focus the password field, and for whatever insane reason it's not just always in focus