NVDA Laggs a lot in Visual Studio Code editor while typing and reading the code #11533
Comments
akash07k
changed the title
|
@feerrenrut |
|
Can you turn on "time since input" logging in the advanced settings panel, with add-ons disabled, do a short test with vsCode and post the debug level log please? |
This comment has been minimized.
This comment has been minimized.
|
cc @isidorn |
Sure @feerrenrut |
|
I can confirm that I've also been experiencing this on my work machine, though its a really old Dell XPS 13 from 2016. Soome other things that might be related:
|
|
@feerrenrut
|
|
Absolutely, same here as well.
|
|
@feerrenrut |
|
Since it is a long log, I picked a random part to inspect where I was sure you were using vsCode: This indicates an average of 140 ms from input to speech. It would be interesting to compare these values to another application that does not have lag for you such as notepad, keeping all other configuration and test approach the same. For future reference, Espeak was used for this test. |
|
So, Should I provide the logs while typing/interacting with notepad too? |
Bro, can you also provide your logs for the easier pin pointing of the problem |
|
Actually I used VS code many times only for generating the log, |
|
@feerrenrut |
|
here're some logs of just using the arrow keys, but this on the machine where I'm not suffering from this. Btw, do I need to choose the "restart with debug logging" option to have the timing logs show up? They wouldn't show up for me otherwise. |
|
Hi bro, |
|
@feerrenrut |
|
Thanks @akash07k, I'll try this on my machine which always has this issue tomorrow at work. |
|
Ok. :-)
|
|
Thanks @akash07k, here is the section of the log I have compared: This seems to average about 50 ms between input and speaking. |
|
Hmm, Don't you find VS Code very laggy as compared to Notepad?
|
|
Found the section of @akash07k's log that demonstrates this horrendous lag, starting from line 220. |
|
@akash07k before going any further with this, are you able to reproduce this on the insider preview of VS Code? It switched from Electron 7 to ELectron 9, with a way newer version of chromium under the hood. |
|
@LeonarddeR
|
|
Some logs on my machine which reproduce this. Typing enter, then pressing the up arrow key to review the text: Typing |
|
Hmm, I noticed the maximum delay of 744 MS in your log at one place which is really really a lot and is very painful. |
|
@MarcoZehe |
|
So, I tested with 2019.2 also, but the same lag persists. sadly. |
|
Seems that this issue is quite complex to fix as well as track down. |
|
@LeonarddeR
|
|
I just got the 1.49 VSCode update and still can't duplicate this against 2020.1. @akash07k , where do you fall on the spectrum from netbook to workstation, and have you tried disabling all extensions in VSCode yet? Someone more qualified than me will probably have better questions, but in terms of a bug functioning like the most typical regression scenario ever, this one does: happens perfectly reliably in 2020.2, happens never in 2020.1. |
It is under investigation. Could you please refrain from asking for updates? We'll provide them when appropriate. |
|
@camlorn
|
|
Ok, let's see.
|
|
I'll see if I can find the time to set up to run from source and bisect this weekend. I suspect there's two causes of lag. I'm not the only person I know for whom 2020.1 works fine. I have read the thread. @akash07k, your comments are hard to follow because you have been splitting up what you've tried across multiple comments back to back so it is possible I missed the answers to my questions. Sorry. |
|
@camlorn
|
|
Finally, |
|
I bisected and this gets weird. The lag is introduced for me and the other person I know who is experiencing this by the rollback of the app module in commit e095f81. And, per the directions in that commit, unchecking enable browse mode on page load gets rid of it for me and massively improves it for him. Notably, entering and leaving browse mode after VSCode loads doesn't reintroduce the lag, either. It's specifically that setting. The NVDA snapshot with the selective event subscription setting doesn't matter for me because there's too little lag left, but for my friend it didn't help. So I think the next thing for this issue is anyone else trying that. Note that configuration profiles are a thing for anyone who doesn't know that already. You can work around it (if this workaround works) by using a configuration profile to selectively toggle the setting rather than gain a responsive VSCode at the cost of a terrible browsing experience. |
|
@camlorn
|
|
Hello all, I tested the workaround and it works for me. Currently I am working on one Go project and was not able to use VSCode. I already had a configuration profile to have spoken indentation, it is helping me a lot while reading the code. Now I switched the mentioned setting and the lag disappeared. |
|
Wow, this workaround also imposes a huge performance increase on my system. This is really one of the ways to go. This issue is currently scattered with lots of comments, making it very hard to follow the line of the issue. Therefore, I'm thinking about opening a new issue that describes the problem more technically. |
Confirmed, and I am really surprised by this.
Please do. As someone who advocated to remove the original app module that forced application mode in VS Code, so the transitions between actual interactions and pieces that were appropriate for reading mode, I am interested in why NVDA suffers so badly if reading mode is involved. |
|
Seriously, it's amazing! It works flawlessly and drastically improves the performance of VS code as well completely eliminates the lag on my 16 GB memory stick and I7 10th gen system. |
|
Really, same here.
|
|
Here is a new try build that should allow enabling the browse mode on page load setting again. |
|
Yes, this seems to be both loading browse mode on documents, such as release notes or similar, as well as have better performance when editing files. But let's wait for confirmation from @akash07k since he can more reliably reproduce the sluggishness than I can. |
|
@LeonarddeR |
|
@LeonarddeR, |
|
I'll test this weekend if there aren't enough other confirms from people. Bit limited on time this week. |
|
This is great! It solves VS Code's slowness, although it introduced a bug in Microsoft Edge Chromium. The controls announce them twice and sometimes three times. Does the same thing happen to anyone else? |
Steps to reproduce:
Actual behavior:
When we navigate/read and type the text/code in visual studio code editor, NVDA laggs a lot and responds very slowly.
For example, If we navigate/read the code in notepad NVDA responds/reads every line quickly but in VS Code, it doesn't happen like this.
Also, If we quickly type the code, most of the times, NVDA announces the typed characters after a delay which is very annoying and problematic.
It doesn't happen with other applications.
Expected behavior:
NVDA should not lag in VS Code editor and should be responsive like it is with other editors.
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
NVDA version alpha-20793,9a4074bc
Windows version:
Tried with multiple Windows builds:
Windows 10 2004, 19041.450,
and latest insider too.
Name and version of other software in use when reproducing the issue:
Visual Studio Code both insider and stable.
Other information about your system:
I7 processor, 8 GB ram, Samsung SSD and also tried with multiple other systems. Same issue persists.
Other questions
Does the issue still occur after restarting your computer?
Yes, always and even after reformatting the system too.
Have you tried any other versions of NVDA? If so, please report their behaviors.
Yes, NVDA stable versions, and the same issue is being observed since months.
If addons are disabled, is your problem still occuring?
Yes, always.
Did you try to run the COM registry fixing tool in NVDA menu / tools?
Yes, but no luck
The text was updated successfully, but these errors were encountered: