News for hackers. Stuff that matters.
Re:Typometer: A tool to measure and analyze the visual laten... by PragmaticPulp on Saturday July 25, 2020 @08:47PM (#23953529)
> 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 laten... by numpad0 on Saturday July 25, 2020 @11:29PM (#23954202)
People tends to compare latencies of devices to human cognition-action loop and declare it irrelevant, but paraphrasing what I’ve heard from a gamer, their understanding is their ability to eyeball sub-10ms range latencies comes from a fact that their I/O loop runs synchronously to real time by training, that added latency can disrupt and force re-adjustments in detectable ways. Like 1PPS signals can be used to sync time in orders of picoseconds, precision of an event is not limited by frequency, only by deviations. Isn’t that interesting?
Re:Typometer: A tool to measure and analyze the visual laten... by toast0 on Saturday July 25, 2020 @10:47PM (#23954008)
I think the latency becomes most problematic when it's inconsistent, and if you want to fix input errors, or move the cursor and then input something.

I've experimented with video games with various amounts of display lag or dropped frames; nothing blinded or anything (although, setting up a blind test sounds fun), and there's clearly an increase in difficulty the farther you get between input and response. Writing code is clearly not Mario Brothers, but small delays can add up.

Re:Typometer: A tool to measure and analyze the visual laten... by magicalhippo on Saturday July 25, 2020 @11:36PM (#23954226)
> I think the latency becomes most problematic when it's inconsistent

Indeed! I don't have a problem using say a SSH console with 1 second lag. After a bit of initial cursing, it works just fine, I can write my code or edit conf files just fine. It's not as comfortable as writing at home, but it's not really a big deal.

However if the lag is inconsistent, say due to packet drops, it's horrible. Even if the base latency is low.

Re:Typometer: A tool to measure and analyze the visual laten... by codinger on Sunday July 26, 2020 @02:34AM (#23954956)
It's funny you mention this, because I like to use vscode over ssh. I believe the editor updates the screen before the change is ever made on the server, so it feels nice and responsive like you're coding on your home machine.
Re:Typometer: A tool to measure and analyze the visual laten... by setzer22 on Sunday July 26, 2020 @03:49AM (#23955252)
Not trying to take merit away from VSCode, but emacs and tramp mode also do that. And not just with remote machines over ssh, docker containers work as well. Also docker containers over an ssh connection (or whatever crazy combination you may need).

You get latency-free editing because the file is edited locally and sent to the server on save. Simple implementation but highly effective.

Re:Typometer: A tool to measure and analyze the visual laten... by mrob on Sunday July 26, 2020 @05:54AM (#23955816)
I use 60Hz keyboard autorepeat for navigation, so latency is very noticeable. I need prompt visual feedback to tell me if my estimate of the autorepeat startup delay is too short or too long. The quicker I get it the shorter the navigation sequence I can make while still having a good chance of hitting the correct frame-perfect key-release timing. Note that reaction time is irrelevant; I anticipate everything and only use the visual feedback for timing adjustment ("rushing or dragging" in drumming terminology).