Feature Request: Zero-latency Typing

[aniljava]

Following articles goes into length describing the issue in general.

• https://pavelfatin.com/typing-with-pleasure/
• https://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/
• https://news.ycombinator.com/item?id=10787812

The subtle typing lag is observed in VS Code in same machine in which the typing is lag free with sublime text and even eclipse. This feature request is to look into the issue and address it if feasible.

[Chillee]

I performed the tests listed at "Typing with pleasure" on my own computer, and these are my results:

[mauro3]

I just ran some typometer tests as well, here the results (note the SD column is the standard deviation):

Here some interesting plots, comparing VSCode behavior of synchronous setup (a new key is only pressed once the last is displayed):

and asynchronous

Also note that some extensions can increase typing latency considerably: SebastianZaha/vscode-emacs-friendly#20

Edit: this is on a Linux system with xmonad window manager.

Edit edit: If you get typometer timing out with "cannot detect char" at some point. Then, to fix, zoom in a lot. Also, you need at least one other line which is wider than the screen to make it work. Also, it's recommended to use a non-block cursor but I didn't see any difference there.

[codecat]

Yesterday I tried switching from Sublime to VSCode, but sadly am returning to Sublime again today because of this issue. Would love to see this fixed in VSCode.

[amritk]

@codecat I was in the same boat as you, but VScode has so much else going for it I switched back again from sublime even with the lag.

[SebastianZaha]

In the case of the emacs extension, the old one had some code that was registering the "type" command to implement some more complex keybinding systems.

I have removed it and I think the latency overhead is fixed. (in v0.8.0 of https://marketplace.visualstudio.com/items?itemName=lfs.vscode-emacs-friendly)

The typing latency is quite spiky though, even with no extensions, at least when trying to graph it with the aforementioned program.

[codecat]

Yes, I notice the input lag without any extensions installed.

[ziriax]

Not only am I experiencing input lag, but lately I also have to press the cut/copy/paste keys rather long, otherwise nothing is copied to the clipboard. Not sure if this is related, but it is extremely annoying. Although of course every good programmer never copy/pastes ;-)

[richardgirges]

Not only am I experiencing input lag, but lately I also have to press the cut/copy/paste keys rather long, otherwise nothing is copied to the clipboard. Not sure if this is related, but it is extremely annoying. Although of course every good programmer never copy/pastes ;-)

I'm experiencing this exact same issue. For instance, I have to explicitly hold down the command key on my mac, and then press C afterwards in order to copy. If I do it too fast, nothing gets copied. In some cases, the C key is registered before the command key and the VSCode will end up typing the letter C into the editor. I don't see this behavior anywhere else other than VSCode :(

[chmln]

For someone with >100 wpm, the input latency is unbearable and no amount of features can compensate for this. It is a text editor after all.

If the behemoth of IntelliJ IDEA could do zero latency, so can VSCode. Its great to see work done on the performance front, and hope this is just the beginning. 👍

[pcgeek86]

I'm experiencing typing lag on a Dell XPS 9350 running Windows 10 1709 (Fall Creators Update). It doesn't seem apparent in other applications, like Firefox and Chrome, but is quite noticeable in Visual Studio Code. I've noticed the typing lag while editing a JavaScript file in particular.

[pcgeek86]

The problem is especially noticeable when your Windows 10 power settings are configured to improve battery life. I'd recommend any testing be done with similar power settings, and reduced CPU performance.

[syifan]

Same thing here with @pcgeek86. I can accept the latency when my laptop is connected to power. But I cannot accept the latency when my laptop is on battery.

[akellermann97]

I love this idea. Really low latency is such a pleasure to use.

[syifan]

Finally got a chance to benchmark vscode on my machine using typometer. Here is the latency distribution when my laptop is on power. I am using a Dell XPS 9360 laptop running ubuntu 18.04. From my experience, I have similar latency in windows. I cannot get typometer working when using battery. Probably it is because the latency is too high. I can feel that on battery has probably 2-4 times longer latency. The related extensions are vscodevim and vscode-go.

Here is the result when I use vscode on battery

To make sure there is no problem with my hardware and os, I also benchmarked GVim and here is the result.

I cannot believe why the latency is so high. My latency is very different from what mentioned in the previous posts. How can I debug where the latency comes from? I tried to use the developer tools, but I cannot figure out too much from the profiling timeline.

[flagbug]

Same issue as @pcgeek86 has. When plugging in my laptop, there is no noticable latency, but as soon as I go on battery, it's unbearable. This is especially noticable when pressing and holding the backspace key, I regularly overshoot the text that I actually wanted to delete.

[rupinder02]

I had the same issue. There was too much of latency while typing. Disabling the in built extensions worked for me.

[sethlivingston]

Disabling some rarely used extensions and turning CPU performance up to 11 significantly improved my latency, but I would still love to see zero latency.

[SamLeatherdale]

Sorry for the necro, but I did notice that starting VS Code with the command line flag --disable-gpu increased the response time significantly.

[Tactleneck]

Is there something that could be done to lower input latency? I can find some time somehow to help with this amazing project but I don't know where to start.
Could the incoming move to electron 3.x help somehow with latency? Because it looks really close to release and it could be better to wait until then. Thank you to all the developers and community.

[wdhwg001]

Actually this latency is the most significant thing that makes VSCode not that "native".

And I don't think it should be heavily related to extensions. It could be hard to benchmark the latency caused by a extension. And it is actually suggesting users to install less extensions to make VSCode faster, which is against the purpose of the extension system.

Any progress on this feature?

[sethlivingston]

This is one of those features that transcends the number of votes its getting. Getting to zero latency or at least much closer would benefit every single user. Please add to the roadmap. Thank you, developers.

[jacktuck]

Unfortunately the only fix would be to get rid of electron (become a native app) and at this point it's probably too late?

[max-sixty]

Does anyone have any actual data on the latency on a recent version?

Even with the headline number (no attribution where it's coming from), this would give some power to the thread

[sethlivingston]

@jacktuck Are you certain that's the problem?

@max-sixty got a camera? :) http://renderingpipeline.com/2013/09/measuring-input-latency/

[MaffooBristol]

This lag combined with the Macbook butterfly keys issues is making my job very, very frustrating. And I'm on a maxed out laptop...

[joshk0]

Does the new Local Echo behavior help with this any?

[MaffooBristol]

Does the new Local Echo behavior help with this any?

I don't think that really applies, as it's only in the context of the integrated terminal, and mostly only an issue when running over SSH

[dmohs]

@matthiasg

The question is, what is the current lowest limit in an HTML rendering scenario ?

I think that is an excellent question. Using the "Is It Snappy?" iOS app, I tested this on a 2019 Macbook Pro. This means I'm using my eyes to judge based on slow-motion capture, but I got 50ms for a plain textarea element in Safari. For comparison, I also got 50ms for Sublime Text.

[basaran]

This is still a problem with vscode, the latency is not noticeable when you are typing a few words, but when you start working on a project, every key feels like there is a chain attached to your fingers. Sublime is better with latency, with less deviations and somehow jetbrains is the fastest around 10-15ms. You really do notice it when you are working. Unfortunately, Jetbrains is not perfect either, they have terrible font rendering if you are on a low dpi display.

To sum it up, this is my experience based on ergonomics:

VsCode:
features: great
font rendering: okay
lag: not okay

Sublime
features: not okay
font rendering: great
lag: bearable

Jetbrains
features: okay
font rendering: not okay
lag: great

There are probably other factors which ruin the typing experience on all platforms, including but not limited to usb interface, screen refresh rate, screen latency, keyboard latency, gpu drivers. Sadly, since 3d became mainstream, it seems nobody really cares about the 2d performance anymore.

[basaran]

For a baseline comparison, this is the typometer results from plain cmd on a windows 10.

As you can see, most of the keys are registered around 6ms, and just compare this to any text editor, you will find yourself in a lot of joy while you are typing random words.

this is VI inside cmd

new windows terminal app

alacritty

My next goal would be to side boot FreeBSD on the development machine and run the same tests there. FreeBSD might have lower latency compared to Windows, and Linux. If anybody had done it already, please share your results.

[CSaratakij]

2021, and this still open..

[basaran]

well, in the end sadly, I switched over to sublime and went back to Arch. It was a painful process to replace all the extensions I had with vscode and still missing AHK. But, while troubleshooting something else today, I ended up disabling C states (power saving) from the bios and that appeared to make a difference.

For those hitting this thread, it's worth a try to disable C states from their BIOS. Intel calls it Enhanced SpeedStep, dynamic cpu frequency etc.

[Tyriar]

FYI I've been looking into this in #161622

[basaran]

Thank you for your efforts, please also keep in mind, adding GPU
rendering will also mean altering the quality of font rendering. For some people it would be for the better, and for some it would be for the worse.

In my experience, there is also the ATI vs Intel situation. Intel appears to have better 2d acceleration compared to ATI (Ryzen).

Another factor for latency to consider would be the windows internals, especially when you have the linux subsystem enabled, I noticed that also appear to add to the keyboard latency.

This whole latency situation is just a big can of worms, affecting everything. Thank you again for your efforts. As of 2022, I am still on Arch, with Sublime and Emacs (nativecomp).

[Tyriar]

@basaran not sure if you're referring to #162445 but I've done an exploration of GPU rendering and it should reduce input latency quite a bit.

adding GPU rendering will also mean altering the quality of font rendering. For some people it would be for the better, and for some it would be for the worse.

I'd appreciate if you could give more details on what you think is good font rendering. The exploration I did was essentially plugging the terminal's webgl renderer into the editor. We have full control over every pixel and defer to a 2d canvas context to draw the text for us (except for "custom glyphs", including SPAA.

I see you said Sublime font rendering was great above, do you know why at the pixel level? How does it compare with VS Code's terminal rendering?

Another factor for latency to consider would be the windows internals, especially when you have the linux subsystem enabled, I noticed that also appear to add to the keyboard latency.

Well there's nothing really that can improve that provided we've done a good job with either VS Code's remote connection in a remote Window. There will always be some overhead in communicating with some other machine.

[Tyriar]

Using the Hack font family. Approximately the same size

Sublime:

VS Code editor:

VS Code terminal:

[basaran]

Hello,

I see you said Sublime font rendering was great above, do you know why at the pixel level? How does it compare with VS Code's terminal rendering?

Sublime allows you to use the older GDI which in my opinion provides better looking (not as fuzzy but hinted enough) font rendering. That also depends on the font too. If you are on a < 140ppi display, and have 20/20 fuzziness would not be as visible of course. But sublime and VS code open side by side, on the same font, at the same size, you could still tell which one looks sharper.

// Windows-only options:
"directwrite": (default) Use DirectWrite for font rendering 
"gdi": Use GDI for font rendering
"dwrite_cleartype_classic": Only applicable to "directwrite" mode, should render fonts similar to traditional GDI
"dwrite_cleartype_natural": Only applicable to "directwrite" mode, should render fonts similar to ClearType "natural quality" GDI
"subpixel_antialias": Force ClearType antialiasing when disabled at system level

Well there's nothing really that can improve that provided we've done a good job with either VS Code's remote connection in a remote Window. There will always be some overhead in communicating with some other machine.

True, but I was referring to the OS latency in general when WSL is enabled. Perhap things are different now as I haven't been on a windows desktop lately. If you have the time, I suggest you try your measurements on a desktop that never had WSL enabled and see how the keyboard responds. Please also see my comment about the CPU power saving settings in the bios.

In addition to disabling the CPU power saving from the BIOS, you could also experiment with disabling the USB suspend settings. I am not sure if it is possible to do on windows, but on Linux adding "usbcore.autosuspend=-1 pcie_aspm=off" made a difference. You could probably do it through udev as well.

I am on the laptop now which is 212 ppi so the camera doesn't capture the pixels as clearly, but I will take pictures of the Hack Mono when I get back to the cave. What size did you set the Hack Mono font and please let me know your screen resolution as well? I can take pictures on 1440p "23.6 and, 1080p 15.6".

[basaran]

Hello, It appears on Linux, vscode (electron) and sublime follow the same fontconfig (since there is no gdi, direct_write), I am not able to provide the screenshots at the moment.

[basaran]

Hello, It appears on Linux, vscode (electron) and sublime follow the same fontconfig (since there is no gdi, direct_write), I am not able to provide the screenshots at the moment. They both look the same way on Linux as it is configured.

[Tyriar]

@basaran thanks for the info, this is helpful!

True, but I was referring to the OS latency in general when WSL is enabled.

That would be surprising, perhaps it's a side effect of early WSL1 as it was more integrated into Windows? WSL2 is essentially a lightweight Hyper-V VM as I understand it.

you could also experiment with disabling the USB suspend settings.

Isn't USB suspend just a power savings thing that only has impact if you're away from your computer for a while?

What size did you set the Hack Mono font and please let me know your screen resolution

Can't remember exactly, I think it may have been ~14px on VS Code and the default in Sublime, not sure which monitor I took those on 😅

[basaran]

That would be surprising, perhaps it's a side effect of early WSL1 as it was more integrated into Windows? WSL2 is essentially a lightweight Hyper-V VM as I understand it.

I was on windows 10 with WSL2. Perhaps it was just a side effect of enabling the hyper-v services, perhaps it was specific to my AMD configuration. Who knows :)

Isn't USB suspend just a power savings thing that only has impact if you're away from your computer for a while?

It sure is, and should not interfere but there are quite a few posts on the forums about it too. For some people lag becomes more noticeable after a sleep-wakeup cycle. In addition to these factors, there is also the matter of the USB port you use. Some USB ports are shared across different devices, and when you have a highly active wifi connection for instance, things would start to lag as well.

Good luck and looking forward to testing the new and improved vs code.

[Balfa]

@aniljava now that #161622 is merged, you might consider testing and closing this issue if it meets your intent.

[dmohs]

This is now, as far as I am concerned, fixed. I just tested VSCode Nightly with "Is it Snappy?" I'm running a late 2013 Mac Pro with a 240Hz display. VSCode (32.9ms from key press to display) compares favorably with MacVim (37.5ms).

I just want to express my gratitude to @Tyriar for their work on this. I am sensitive to latency, and for this reason I have had to simply observe from afar my colleagues usage of VSCode and some of it's fantastic features. Now I get to join in on the fun. Thank you so much for giving me access to this tool.

[Tyriar]

@dmohs good to hear it's improved! Still, this should be an ongoing effort. 32.9ms is still pretty bad imo 🙁, I don't blame you for being sensitive if it was even higher than that.

[avdhoot]

@dmohs Does not look like #107016 (comment)

[basaran]

Here is another update. I am still on Arch and a few weeks ago, I discovered something else. In my setup, in addition to the c-states, disabling virtualization extensions also reduced the input lag and standard deviation on Linux. The new intel processors have dynamic cpu scaling, so disabling performance saver from the bios may not have much effect. I would suggest disabling the dynamic scaling, and switching to usermode and set a fixed frequency.

# enable userspace power governow
# sudo sh -c "echo passive > /sys/devices/system/cpu/intel_pstate/status"

# set freq
sudo sh -c "cpupower frequency-set --governor userspace"
sudo sh -c "cpupower frequency-set --freq 2.4GHz"

[Tyriar]

We'll be starting the effort to build a webgpu-based renderer in the editor this iteration. You can read about the prototype and follow along in #221145