Live data from Hacker News

Typometer: A tool to measure and analyze the visual latency of text editors

pavelfatin.com

11–20 of 104 posts

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#11
I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms.

If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely has some input processing as well, adding anywhere from 10-20ms before it sends the frame to the physical display. Add a few milliseconds here and there for input processing and even the response time of the physical pixels, and you're looking at something like 50-60ms minimum for total display latency before you factor in the software.

Using 144Hz FreeSync or G-Sync monitors can shorten that update time, but you're still looking at 30ms end-to-end latency in even the fastest setups, and that's before you account for software processing lag.

The difference between Sublime Text responding in 11.4ms average and Atom responding in 28.4ms average is difference of almost exactly 1 frame of latency for a typical 60Hz monitor. Add up all of the other sources of lag (buffering, monitor input lag) and you're looking at something like a 5 frame latency instead of a 4 frame latency. Still less than the blink of an eye (literally).

From another perspective: If you really believe that you're sensitive enough to feel a difference between something like Sublime Text's 11ms processing latency vs. Atom's 28ms latency, then you might want to invest in a proper 144Hz gaming monitor with low input lag, as it would improve your experience by the same margins. A gaming-specific keyboard might also help, as average keyboards can have 10-20ms of input lag before the keypress registers with the OS (Source: https://pavelfatin.com/typing-with-pleasure/ ) Realistically, though, I doubt many people could A/B test the difference between a 1ms and a 30ms latency editor under ideal conditions, let alone while typing out some code.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#12

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

>The difference between Sublime Text responding in 11.4ms average and Atom responding in 28.4ms average is difference of almost exactly 1 frame of latency for a typical 60Hz monitor

That is looking at the average latency for Atom. If you look at the max latency Atom, it is 60ms compared to 15 ms for Sublime text. That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for the average person.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#13
post #5

The 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 a…

Vim + Alacritty + Gruvbox = Happiness.

For me at least.

I've found that I get perfectly passable syntax highlighting with vim, and haven't needed anything else on my current install. If I did use an editor other than vim, I would probably use VSCodium because open build, and I do really like the visual style.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#14

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

>The difference between Sublime Text responding in 11.4ms average and Atom responding in 28.4ms average is difference of almost exactly 1 frame of latency for a typical 60Hz monitor That is looking at the average latency for Atom. If you look at the max latency Atom, it is 60ms compared to 15 ms for Sublime text. That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for t…

> That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for the average person.

Having done some UX work in this area, I can say that people greatly overestimate the effects of latency on text entry when they're just looking at the numbers. End-to-end lag is more obvious in situations like dragging objects, but even then people manage to work around it.

Typing isn't performed on a tight feedback loop in the brain. We don't wait for the letter to appear on screen before starting the process to press the next key.

Typical human reaction types are on the order of 250ms for a simple visual stimulus. Recognizing letters will take even longer. A difference of a few 10s of milliseconds isn't generally going to be noticeable for typing unless you're really going to great lengths to A/B test.

Consider that people can SSH into remote machines all of the time with 100s of milliseconds of latency. The experience may not be optimal, but our typing doesn't fall apart over SSH.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#15

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

>Your monitor likely has some input processing as well, adding anywhere from 10-20ms before it sends the frame to the physical display.

This is more in the 1-2ms range, even for non-gaming devices.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#16

The 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…

A few months ago I found my old GameBoy and played through part of "Kirby: Nightmare in Dreamland". I know its not the most well-known game, so the relevant detail is that it relies a lot on timing and quick movements.

I was completely blown away by the responsiveness of the controls. The control feedback was instant, frames were rock-solid, and there were no loading screens at all.

When I put down the game, I was just tremendously sad. I'd forgotten what instant feedback felt like.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#17
post #15

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

>Your monitor likely has some input processing as well, adding anywhere from 10-20ms before it sends the frame to the physical display. This is more in the 1-2ms range, even for non-gaming devices.

Good G-Sync or FreeSync gaming monitors can get down to low single digit millisecond numbers, but the typical 60Hz non-gaming monitor or laptop display will be more in the 8ms-15ms range.

Example: https://www.rtings.com/monitor/tests/inputs/input-lag (Scroll down to the non-gaming monitors)

The gray-to-gray response time for the physical pixels is in the neighborhood of 2-4ms, so the additional latency comes from the processing.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#18

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

If you really believe that you're sensitive enough

It's pretty obvious when using extended shortcuts or a string of keys that are committed to muscle memory, like Ctrl+Shift+P (+ first letter of a cmd) or Ctrl+K combos.

Imagine playing an instrument wired up to headphones and then adding a 30-60 ms delay... the longer the delay the more it creates that "off" feeling

Don't forget too, those are bare metal calculations. Stick those apps inside a VM like many devs do or add some other latency along the I/O chain and it all helps to create a perception of lag.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#19
post #18

I'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely h…

If you really believe that you're sensitive enough It's pretty obvious when using extended shortcuts or a string of keys that are committed to muscle memory, like Ctrl+Shift+P (+ first letter of a cmd) or Ctrl+K combos. Imagine playing an instrument wired up to headphones and then adding a 30-60 ms delay... the longer the delay the more it creates that "off" feeling Don't forget too, those are bare metal calculations…

> Imagine playing an instrument wired up to headphones and then adding a 30ms delay

We need to keep these numbers in context. 30ms delay would appear as an echo if you were playing an instrument and also listening to a 30ms delayed version of the same sound.

However, you're not feeling the latency. You're noticing the presence of two distinct signals. That's why UX input latency matters much more when you're doing something like dragging across the screen with your finger on the screen: You visually register the distance between your finger and the expected location.

However, when you're typing a memorized series of letters on a keyboard, you're not comparing the keypresses to the letters appearing on the screen. You already know what you're typing and what you expect to see on the screen. Visual stimulus latency is on the order of 250ms, so you wouldn't even begin to start processing types for an order of magnitude larger than the latency of these text editors, for example.

Most of us are operating with regular 60Hz laptops or monitors. End-to-end latency from physical key press to physical color change on your monitor might be as high as 50-60ms even with zero-latency software.

Re: Typometer: A tool to measure and analyze the visual latency of text editors

#20

The 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 b…

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

If you try running a screen reader, such as Narrator (built into Windows; edit: turn it on and off with Ctrl+Win+Enter, even on the logon screen), you should find that even if the focus somehow gets away from the Password field, you can get back there with the help of speech output. Logging in blind doesn't have to mean logging in with no means of orientation.

(Disclosure: I'm a developer at Microsoft on the Windows accessibility team, working on Narrator among other things.)

Post reply on HN