Hacker News Reader

Comment by Cannabat | Hacker News Reader

> respond to your keystrokes on the next display refresh

Claimed insertion latency for a keystroke: - zed 58ms - subl 75ms - vscode 97ms - clion 83ms

60 Hz displays refresh once every ~16.6ms. 58ms to insert a character is ~3.5 frames. My laptop can do 120 Hz, and other monitors can even do 300 Hz.

Yeah, it's a lot faster than the other editors, but 58ms seems really slow - definitely not "next display refresh". All of them seem really slow.

View on HN

Much of that is latency added by the design of modern compositors (see "the compositor is evil").

The good-ish news is that as the frame rate goes up, compositor latency goes down, as it's usually an integer multiple of frame refresh time.

I'm also interested in influencing the design of next gen systems to reduce compositor latency, but I'm apparently pretty much alone in that interest.

Xilem seems to be heavily focused on using WebGPU. One doubt I have is: is it possible to have tight integration with the system's compositor using such an abstraction? For example, on Windows looking at the documentation for the DirectComposition, it seems that things are designed precisely to work optimally with DirectX. So my impression is that one would really need to use the native graphics APIs on each system to achieve optimal input latency.

It's a good question and one we're looking into. We're not planning tight integration with the system compositor on our 2024 roadmap, partly because it's extremely platform dependent, and presents compatibility challenges (you basically don't get it on X). But even for damage regions, which is on the roadmap, we're going to need to extend wgpu.

As computers got more complex, latency increased. It's really pretty remarkable to see how things have changed over the years[1]. I do agree that 58ms seems far outside of the range of "next display refresh", however.

[1] https://danluu.com/input-lag/

> These are tests of the latency between a keypress and the display of a character in a terminal

Wow, the numbers are entirely unexpected. I want to see the latency when you have no display server, having booted directly to a shell.

I imagine modern competitive twitch-reflex videogames (fps, fighting) must have far less input latency - 100ms must be totally unacceptable. Suppose that's the power of a GPU.

I'm interested to know what people's insertion latency is on Neovim with similar IDE-like plugins, and LSP and Copilot running.

Same. I'd hope that using LSP and Copilot would not meaningfully impact insertion latency, though - I'd expect those to be fully async, in a separate thread.

Reply on news.ycombinator.com