It is, because there may be multiple things synchronizing their inputs and outputs to the refresh, which causes the refresh-related latency to be a number of frames. E.g. in some Linux compositors inputs are latched with the refresh, apps themselves may render in sync, and the compositor also draws in sync; the GPU driver would also introduce at least a frame of latency typically.

Another factor is that some (many?) 60 Hz displays buffer a whole frame themselves, and often don't have quick response times. If you go from a 10 ms response time IPS screen with a frame buffer to a 120 Hz gaming screen with 2-3 ms response time, you already got a difference of about 25 ms just in the screen itself.

8 ms is hard to notice. 50 ms less so.

The difference is pretty huge, even on systems that are much better tuned than Linux desktops (e.g. Windows 10).

That being said, while it is very nice and feels nice, it's not necessary for development work; I spend most of my days developing on a system over a VNC connection through a VPN, so the basic input lag of that setup is around 200-300 ms. Gnarly yes, but not particularly bad for text input. You get used to just do everything very slowly with the mouse.

> The difference is pretty huge, even on systems that are much better tuned than Linux desktops (e.g. Windows 10).

What would you suggest, or either Windows 10 or Linux, to get the lowest latency in a terminal?

If you want the lowest latency in a terminal, use a vga textmode console with a ps/2 keyboard. That's pretty hard to get on windows 10, so I'd go with Linux.

I agree. Make sure it's not a framebuffer, because it also adds latency.

Unfortunately, if you want a normal sized font, this is not possible with modern "high resolution" displays

In the article: > We get a 90 ms improvement from going from 24 Hz to 165 Hz.

As per the linked article, the observed delay improvement isn't one frame, more like ~3 frames. It doesn't go up from 1/24 to 1/165, it goes from 2.5/24 to 2.5/165.

Computer software waits a lot more than it did in 1977. That's why 240hz displays feel much more snappier even if it's supposed to be less noticeable -- you're waiting for same 3 frames, but they pass by much faster.

I guess so, the difference between 8ms vs 16ms is not much for 1 frame.

Though in my totally subjective experience it feels better.

Interestingly the person who did this latency test also did a keyboard latency test:

https://danluu.com/keyboard-latency/

Compared to the slowest keyboard measured it's possible to shave 45ms which if you were latency sensitive would be the biggest reduction.

> A major source of latency is key travel time. It’s not a coincidence that the quickest keyboard measured also has the shortest key travel distance by a large margin. ... Note that, unlike the other measurement I was able to find online, this measurement was from the start of the keypress instead of the switch activation.

That's disappointing. He isn't measuring latency nearly as much as he's measuring point of actuation.

Well, thats a reasonable point of reference: for a user, his starting point is clicking the button, the rest is not under his control

I don't think it is.

With a clicky switch I expect it to actuate when I hear it. With a tactile switch I expect it to actuate when I feel it. With a linear switch it depends on the switch. You can get linear switches that actuate as soon as you'd like.

The more I think about this the more useless it seems. Several of the keyboards he tested come with your choice of switch, different switches with different actuation points, and so you can't just say Keyboard X has a latency of Y without mentioning what switch you were using if you're going to measure from the beginning of the keypress.

Personally I don't think start clicking as click action is done. If I want to minimumize the gap, I'll use speed switches or thin keyboards.

yes, shaving ~8ms