microsoft
Feature Request: Zero-latency Typing
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.
I performed the tests listed at "Typing with pleasure" on my own computer, and these are my results:
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: https://github.com/SebastianZaha/vscode-emacs-friendly/issues/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.
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.
@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.
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.
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 ;-)
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 :(
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. :+1:
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.
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.
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.
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.
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.
I had the same issue. There was too much of latency while typing. Disabling the in built extensions worked for me.
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.
Sorry for the necro, but I did notice that starting VS Code with the command line flag --disable-gpu increased the response time significantly.
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.
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?
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.
Unfortunately the only fix would be to get rid of electron (become a native app) and at this point it's probably too late?
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
@jacktuck Are you certain that's the problem?
@max-sixty got a camera? :) http://renderingpipeline.com/2013/09/measuring-input-latency/
I updated to 1.29, experienced input lag and then reverted to 1.21.1. Sadly, most of my extensions stopped working immediately after this upgrade process. If possible, it'd be great to know about regressions, prior to uninstalling a version that does work to install one that does not.
An alternative could be a Revert option to allow ppl to try the new features and test regressions prior to uninstalling the previous version fully.
As someone who has a 165Hz display its very noticable even pressing a single key in VS Code, it feels too delayed and heavy, to the point that it makes every keystroke feel as if i'm lifting 50g with a finger.
I honestly don't understand why a code editor choose to ignore its typing experience. Any updates?
This makes vscode unbearable for me. Even with the --disable-gpu -option the input lag is too much for me. I like what vscode brings to the table compared to sublime, but as for now, I'm sticking with sublime.
Yeah it's an issue that makes me uncomfortable using vscode for extended periods of time, especially when my computer is compiling or doing anything processor intensive ---
An easy latency test is to try highlighting a bunch of lines of code in VSCode and see the highlight visibly lag behind your cursor. Sublime Text and Microsoft Visual Studio do not show any latency between cursor and highlight.
