I type relatively quickly (95 wpm) and I didn't even notice the delay until "really not great" (100 ms) and it didn't bother me until "we're done here" (200 ms). I think it has more to do with expectations than it does anything else... A "slow" text box just isn't that annoying. I'm usually waiting for my fingers to catch up with my brain anyway, so there being an extra few ms doesn't change much. It's a little disconcerting to see the text all catch up at the same time and back spacing at the slowest setting was annoying. But still not seeing what the big problem is.
I suspect delay impacts more slow (or error prone) typists who rely more on visual feedback, whereas fast typists presumably generally rely/trust more just physical feedback.
I'd tend to agree that it matters the more you rely on visual feedback. I type on unfamiliar keyboards a lot and use visual feedback almost exclusively; 10ms latency was imperceptible, 20ms was very noticeable, and the 50ms latency was at the point of being unbearable (I'd go find another machine to work on or something before typing with that for more than a couple minutes).
I'm a fast touch typist, but input latency really throws me off. If there's more than about 150ms of key-to-screen latency, I'm faster with my eyes closed. I normally scan the screen as I'm typing so I can quickly backspace over a typo, but I find it really difficult to plough ahead if the screen isn't keeping up.
I've had a similar experience with audio systems - I can play guitar tolerably well even if I can't hear what I'm playing, but >40ms of latency will turn me into a ham-fisted mess.
I'm probably still easily in the 80s WPM, and could practice back up into the 100s in a day or two. Input lag doesn't so much throw off my typing as it makes computing feel kinda remote and gummy rather than real and crisp. You lose the feeling of a direct connection between your input and the computer. Like you're poking the keys with a stick underwater, no matter how fast you type.
Even this text box, on HN, is noticeably disconnected compared with, say, DOS on an IBM PC-XT, or your average text input area on early Apple computers, BeOS on a first-gen Pentium, QNX on same, that sort of thing, and that's without applying the linked site's extra latency. Everything, just about, is a bit muddy on a "modern" computer. iOS is the closest thing to an exception and even that's gotten worse over the years.
When it finally loaded, I found it horrific fun. My sentiments lined up very closely with the labels: FINE, COULD BE WORSE, and then IT'S WORSE and worse.
I thought the buttons at the top ("Fine", "Could be worse", ...) were survey answers. Nope, they are how you choose the input latency.
The "We're done here" button is only 200 ms, and "Surprise me" only goes up to 500 ms. I have experienced far worse and variable latencies over Windows Remote Desktop and SSH due to bad Internet connections - like multi-second delays. This demo pales in comparison to the real world.
I was able to notice it at the 30ms mark, and it gave me a flashback to trying out Eclipse and NetBeans when working on some big unfamiliar project years ago. Couldn't make myself use either, no matter how useful all of the magic tools were...certainly in part because they both had noticeable input lag, which I've now learned I find super annoying.
Funny this comes up today because I was thinking of getting back to vim fully instead of VSCode+vim extension and used vscode as a debugger only (love the UI!).
Fun. But I don’t feel it’s entirely accurate. I don’t mind typing with a delay as I can watch my keyboard, but clicking on moving objects with a variable delay is quite dreadful.
For me nothing much changed up to "really not great" - only then did I start to notice the delay.
But "variable latency mode"? That made me more nostalgic than annoyed.
It was an instant flashback into the 90s, running Irssi in screen over SSH on a slow dial-up connection while downloading MP3s. Happily chatting away.
Reminds me of operating servers via ssh when on 3g on a moving train.
(Yes, I know mosh exists for this reason)
It actually made me realise that my normal typing in my browser is quite high latency, since the 5-10ms exacerbated something enough to the point where I notice it even though there's no added latency now.. one of those "cannot unsee" moments and it's going to cause me to go insane.
Funny you mention it. I posted a question about this on superuser. Its currently the second result when doing a google search on "visual studio input lag". The issue disappeared when running in single monitor mode, but I couldn't determine the root cause.
I used to work at a company that gave our two machines: a beefy desktop with lots of RAM, many cores, two GPUs, a fast disk, etc., and a mid-range Apple laptop. For consistency reasons, my main development environment ended up being a tmux session running on the desktop, and I would ssh in to the machine from the laptop.
The latency hovered around 100ms (it's not great), but it went up and down throughout the day and as I moved in and out of the office. Honestly, it isn't so bad. I find after years of working like this I keep enough of a mental model of what I've typed that I'm not bothered by even the "we're done here" setting.
While we're doing asides: In days gone by I worked with a person who was regularly 2 or more full window switches ahead of Emacs. Meaning, they could type a switch window command and using their memory of the code and point there type a search/delete/change, switch to a 2nd window, do the same, etc all before the 1st window rendered.
Of course this was on slow computers so it was not so much a feat of speed but rather how much of the full code they were holding in their head at any time.
300 baud tty input was like this. ah.. the memories (asr33 teletype in the house, followed by an olivetti, proceeded by a remote input cardpunch on 75baud)
This takes me back fifteen years to when I "upgraded" from a 1Mb/s high-bandwidth cable internet service to a more expensive 128Kb/s symmetric DSL connection because I was working from home over ssh. I went from "really not great" to "fine"/"could be worse", and it made my life so much better.
On my iPhone I find everything up to maybe 0.6 seconds to be just fine. Part of this may be being used to using SSH over VERY poor network connections.
I think the biggest frustration with latency is not the latency itself, but rather when latency is combined with the possibility that what you entered didn't register at all and the time pressure of having only 15 seconds of signal to submit your command - situations that often occur when using Internet based sessions in the wild.
The other source of annoyance is trying to "not crash the system". Often when a system presents high latency like this, I tend to consciously pay attention to how many "buffered" inputs I'm sending for fear of crashing something, and that self-throttling can get tiring.
Bonus points if this results in mis-clicking something dangerous or irreversible, like "delete", "cancel","post","send", "close", "exit without saving" or the like.
In the same way that browsers refuse to do certain things unless coupled with human input (like open a pop-up window, or submit auto-filled form data), they should refuse to send a click event to an element that hasn't been stationary for a short while.
It would need to be defeatable for "game mode" though, for games involving clicking moving targets. Any other edge cases to consider?
This is why most platforms provide both raw and semantic events: mousedown and mouseup are instantaneous and reflect the raw input, but click is meant to describe user intent to initiate an action. Leaving the raw events for games but requiring semantic events for dangerous actions seems like a decent compromise.
Worth pointing that the number presented is presumably additional delay on top of the inherent delay of your setup. That means that especially in the lower end the values are not comparable between people on different systems.
Eh, its not really that bad. The variable latency needs to be much more extreme to be noticeable. 250ms is about the threshold where I start to feel hampered. So going from 34ms->78ms->150ms->56ms->14ms really isn't an issue. If I was seeing 100-200ms jumps, I think that would have a much bigger feedback effect, similar to to hearing your own voice on delay. Especially if it changes on a `space` rather than every character. Just long enough for you to get used to, and anticipate, the delay. Then a wild change.
When I type it sometimes stalls for a while and then dumps a whole bunch of characters at once (much faster than I actually typed them). Anyone else having that issue?
This reminds me so much of macOS Finder. Back in 10.9 there was no delay when creating a new folder and typing a filename. This evening I accidentally caused Finder to navigate away from the "untitled folder" by starting to type the filename too quickly after pressing Command-N. It's a really frustrating UX, and feels very similar to a 200+ ms delay.
Apple needs another of their performance-focused releases, like that one where one of the biggest features was reducing memory use. For MacOS and for iOS, focused on reducing system latency in both cases. Both are a lot laggier than they used to be, and the power of the hardware under them barely seems to matter.
74 comments
[ 4.7 ms ] story [ 142 ms ] threadI've had a similar experience with audio systems - I can play guitar tolerably well even if I can't hear what I'm playing, but >40ms of latency will turn me into a ham-fisted mess.
Even this text box, on HN, is noticeably disconnected compared with, say, DOS on an IBM PC-XT, or your average text input area on early Apple computers, BeOS on a first-gen Pentium, QNX on same, that sort of thing, and that's without applying the linked site's extra latency. Everything, just about, is a bit muddy on a "modern" computer. iOS is the closest thing to an exception and even that's gotten worse over the years.
The variable latency mode was truly annoying.
The "We're done here" button is only 200 ms, and "Surprise me" only goes up to 500 ms. I have experienced far worse and variable latencies over Windows Remote Desktop and SSH due to bad Internet connections - like multi-second delays. This demo pales in comparison to the real world.
Is it possible to describe what it is without spoiling anything?
Funny this comes up today because I was thinking of getting back to vim fully instead of VSCode+vim extension and used vscode as a debugger only (love the UI!).
I've never learned vim proper (started with Atom and vim-mode-plus), but I keep thinking it might be time to dive in.
But "variable latency mode"? That made me more nostalgic than annoyed. It was an instant flashback into the 90s, running Irssi in screen over SSH on a slow dial-up connection while downloading MP3s. Happily chatting away.
Individual perceptions are weird.
(Yes, I know mosh exists for this reason)
It actually made me realise that my normal typing in my browser is quite high latency, since the 5-10ms exacerbated something enough to the point where I notice it even though there's no added latency now.. one of those "cannot unsee" moments and it's going to cause me to go insane.
https://superuser.com/questions/715607/improving-resolving-k...
The latency hovered around 100ms (it's not great), but it went up and down throughout the day and as I moved in and out of the office. Honestly, it isn't so bad. I find after years of working like this I keep enough of a mental model of what I've typed that I'm not bothered by even the "we're done here" setting.
Of course this was on slow computers so it was not so much a feat of speed but rather how much of the full code they were holding in their head at any time.
Unless it was 2.4Ghz, I suppose; all bets are off then.
I think the biggest frustration with latency is not the latency itself, but rather when latency is combined with the possibility that what you entered didn't register at all and the time pressure of having only 15 seconds of signal to submit your command - situations that often occur when using Internet based sessions in the wild.
The other source of annoyance is trying to "not crash the system". Often when a system presents high latency like this, I tend to consciously pay attention to how many "buffered" inputs I'm sending for fear of crashing something, and that self-throttling can get tiring.
It would need to be defeatable for "game mode" though, for games involving clicking moving targets. Any other edge cases to consider?
Can't figure out if the site is down or if this is part of the test.
Of course, dialup was worse. You can never really get used to 300ms.
I think something about the drawing is the issue.