Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Slow reponse to scroll and typing #107016
Comments
|
(Experimental duplicate detection)
|
|
@RLesma Does this reproduce when disabling all extensions? Press
|
|
I do have this issue now too. I don't think I had in any previous version. My observations:
Edit: My "about" information: Hope this helps! |
|
I also noticed some lagginess when typing / scrolling on my end (1.49.1).
|
|
Experiencing the same problem. My about info: Significant performance drop when editing files that have some sort of syntax highlighting. Recorded performance while typing/scrolling and saw a lot of warnings about "cumulative layout shift". Edit: |
I just did that, and it is still slow. Definitely not an extension issue. |
|
Downgrading to 1.48.2 also solved the issue for me. |
|
@deepak1556 Would you need more info here ? (this seems similar to #106456 , #106939 which are all on Windows) |
|
Thanks to the traces from @Minkyu-Choi and @Perh0rd , I was able to see a problematic area during the scroll operation. I was not able to find the same stack in a trace from my local dev box, the AXObject is something that gets constructed for accessibility tree in the renderer, this gave a clue as to maybe the problem happens when accessibility is involved. Turning on the screen reader and performing the scroll did create the same stack along with a visible slowdown. This brings me to my question, is everyone here seeing the issue had screen reader enabled ? |
|
@deepak1556 Do you mean narrator enabled? Then, narrator is disabled. |
|
Thanks for confirming, one more thing to try, can you launch with |
|
Unfortunately, scroll behaved same with that option. |
|
@deepak1556 I have seen this in the past -- electron/electron#7208 . Electron would enter accessibility mode on laptops with touch screens. IIRC the root problem was that on Windows there was no clear API to find out if a Screen Reader is attached, and the way to determine that was by checking some Windows events if they appeared to be similar to the ones that Screen Readers typically send. I'm not saying this is the same issue, but in that case there was also a lot of slowness experienced. So IMHO I think there are 2 issues here:
|
I do not use the screen reader |
|
This shows that the narrator is not enabled, I think |
|
Just to add, I do not have a touchscreen neither |
|
Thanks @alexdima for the additional context,
https://github.com/electron/electron/blob/master/shell/browser/native_window_views_win.cc#L196-L225 Considering users facing the issue don't have narrator enabled, definitely a bug in either electron/chromium entering accessible mode by default.
Don't have a definitive answer for this, workaround given by chromium authors to prevent this particular stack was to add a non-transparent background color. We might want to check on this perf issue with newer versions of chromium. I am currently building a exploration release based on Chromium 87. |
|
Here is exploration build based on chromium 87 https://az764295.vo.msecnd.net/exploration/53c0ab95bb770a8f3f869e81bb9da200708e6700/VSCodeUserSetup-x64-1.50.0-exploration.exe , can you check if the slowdown is still visible. Thanks! One more question to users facing the issue, are you running windows on some VM ? |
|
Apart from testing the exploration builds, can you also check if launching |
|
@deepak1556 code-insider with --disable-rendere-accessibility options shows much better scrolls both keyboard and wheel than before! |
|
Also confirming that with --disable-renderer-accessibility, scrolling frame rate when from 1-10 FPS up to 60 FPS. |
|
I've been going crazy the last few days trying to figure out why the editor is so dang slow and finally found this, it's smooth again! (Even tried with all extensions disabled) VS Code version: 1.51.1 |
|
I believe I've found a reliable way to reproduce this issue (on my computer at least):
Other Info about my computer:
|
|
update: after almost a week of code working just fine it's gone back to stuttering when scrolling through large files. |
|
1.52.0 does NOT resolve the problem here. Removing --disable-renderer-accessibility, I'm back to a solid 5-10 fps. |
|
Strangely, installing the update to 1.52.0 temporarily fixed the issue, but as soon as I go through the reproduction steps in #107016 (comment) or #107016 (comment) the issue returns. |
|
I've been struggling with the performance issue recently on Windows 10 x64.
I got this error message though after applying the flag: [1213/005014.191:ERROR:registration_protocol_win.cc(103)] CreateFile: The system cannot find the file specified. (0x2)
Warning: 'disable-renderer-accessibility' is not in the list of known options, but still passed to Electron/Chromium.Really hoping that this can be resolved without this flag on Windows. |
|
The use of $ code --disable-renderer-accessibility .
Ignoring option disable-renderer-accessibility: not supported for code.VSCode launches but is still super slow. I'm also on v1.52.1. |
You can launch VSCode from Windows and then open a WSL project, it works |
|
I was almost going to switch to a different IDE and/or reinstall OS xD before finding out this issue.. Update: Adding |
|
I removed Logitech Options app then restarted system. Hardware and native OS pointer/wheel sensitivity working perfectly. It is not solution but enough for until fix this. I think problem is not about compeletly electron or chromium. Options app Highly depends to logitech and OS. I will waiting next updates. |
|
|
|
Just another confirmation that on vscode 1.52.1 launching with --disable-renderer-accessibility fixes dramatic slowdown for me. |
where do we need to add this line? okay so i add this in the shortcut properties > target. I dont feel there is any difference. Touchpad laptop is super smooth, wacom tablet feel laggy, like it has low FPS. Same as when i use the scroll wheel on there |
|
What am I doing wrong? |
Nothing, mine does that too. Even with the warning it still seems to work for me. |
You're not doing anything wrong. It ain't supported. But it will by subprocess. Just ignore it. |
Add it on shortcut after .exe or you can simply type in cmd |
|
@dylanwulf, @gencer |
|
@deepak1556 Is there anything we could do on our side, like detect this case somehow and proactively inform users that the renderer has entered accessibiliy mode or something like that?? |
|
Never open MicrosoftVirtualKeyboard in your current Window sessions.
--- EDIT |
Is this something you'd consider implementing @alexdima - if I may respond to your latest comment on this issue? I'd find this very useful as I assume this would set the argument everytime VSCode is opened, no matter how. Personally, I constantly use the "Open with Code" option in the Windows Explorer context menu. |
|
There is a setting |
|
@rzhao271 No, |
|
I've also seen that running code with I've got a tiny suggestion for everyone else trying to use Code with the aforementioned flag all the time: How to edit Code CLI arguments globallyYu can just edit your On Windows you can find these files in # File: code (used by WSL)
@@ -58,5 +58,5 @@ elif [ -x "$(command -v cygpath)" ]; then
else
CLI="$VSCODE_PATH/resources/app/out/cli.js"
fi
-ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"
+ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --disable-renderer-accessibility "$@"# File: code.cmd (used by Windows)
@@ -2,5 +2,5 @@
setlocal
set VSCODE_DEV=
set ELECTRON_RUN_AS_NODE=1
-"%~dp0..\Code.exe" "%~dp0..\resources\app\out\cli.js" %*
+"%~dp0..\Code.exe" "%~dp0..\resources\app\out\cli.js" --disable-renderer-accessibility %*The Start Menu shortcut does NOT use above files, they directly run "Code.exe" so you'll want to edit that one too. I'm not sure if this edits will survive updates. |
and others
Issue Type: Performance Issue
It is not slow to start-up, it is slow to do anything in the text editor (scroll, find, type, etc). For example, when scrolling, the screen is unable to keep up with the mouse wheel and it will keep scrolling for a while after I stop the mouse wheel. I disabled the extensions I installed lately, and also reduced the amount of files in the workspace.
VS Code version: Code 1.49.1 (58bb7b2, 2020-09-16T23:27:51.792Z)
OS version: Windows_NT x64 10.0.19041
System Info
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
opengl: enabled_on
protected_video_decode: enabled
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
Process Info
Workspace Info
Extensions (11)
The text was updated successfully, but these errors were encountered: