Item — HN Reader

I'm working on a fast text renderer for xi-editor, and am similarly quite concerned about end-to-end latency. I've also experimented with the high speed camera, but my main testing rig is an Arduino that injects USB HID events and then measures light from the screen. I expect to publish results soon. One difference from Dan's results is that it doesn't take the keyboard's latency into account, as that's synthesized.

The good news is that we can get to even better results than Apple 2 by choosing pieces carefully. This is not my final result, but I'm seeing about 19ms from USB to light on a 2017 Macbook Pro 13" connected to a 144Hz monitor.

Given the unexpectedly large contribution of the keyboard, I think there is a _tremendous_ business opportunity in empirically validated actual low latency keyboards. Gamers will eat these up, but I would buy one in an instant for coding.

3 comments

There are gaming keyboards with 1000hz poll rates.

Those claimed polling rates don’t necessarily translate into low latency. An article that showed up here a while ago touched on that. https://danluu.com/keyboard-latency/

It appears that the main source of latency in these tests are from key travel time, which does not accurately represent the speed of the keyboard. Gaming keyboards often has a lot of key travel before the key is triggered. This is on purpose to give better control of the key and allow for "floating" where the key is half way pressed and quickly switched between actuated and non-actuated state.

For a better test, in my opinion, the key actuation point should be determined and the timer started at that point. Of course this depends on what you want to test. But to say that a gaming keyboard is slow, just because there is more key travel, is inaccurate.

The test mentions the floating and comes to the same conclusion as i: it takes time to get to the floating position and that adds to the latency.

but this probably wouldn't feel laggy, right? because your brain is going to expect full-key-down to be the point at which text appears. especially if that point is well-expressed mechanically (eg, a click).

this would be like saying a physical kick drum or high hat is laggy, because theres a delay between when your foot starts moving and when the sound happens. (which would be silly!)

I think what you'd want here is for the tactile click to be at the actuation point. My understanding is that many or most mechanical keyboards today can't claim this.

Or maybe there is some optimal separation a key should have between the actuation point the tactile click point to account for the latency of the human's nervous system, which would do an even better job of reducing the effects of latency than if the two events were at the same point?

Emphasis on "empirically validated actual low latency keyboards." Dan Luu has tested those purportedly high performance gamer keyboards before and found them mostly lacking.

Cool hack with Arduino HID. What light sensor are you using?

My parts list is here: http://a.co/fltiKey , and the light sensor is one of those Chinese MH-Sensor-Series Flying Fish with a photodiode. The difference between space and '#' at a normal terminal/editor font is around 20 counts (out of 1024 total), which is plenty enough to detect reliably, and the response time is easily <1ms, as cross-checked by the 1000fps camera.

Wouldn’t a text renderer live outside of the xi backend? So you’d have to write one for each front end? Maybe not?

Yes, this is in the front end, not the core. My current implementation is in Swift, using OpenGL, but I'm contemplating writing a cross-platform one as well (maybe Rust/Vulkan because that would target most newer devices other than Apple).