vscode: Slow reponse to scroll and typing

Is there any way to set this flag by default in a link?

• Right Click on the vscode applicaiton icon
• Select properties
• Under shortcut tab
• Set the Target to code.exe --disable-renderer-accessibility

i’am able to pinpoint issue for my PC (win10 19043 x64 / NVIDIA 1060) code 1.69.2

issue: scrolling seems like lagging behind, app behave not responsive --disable-gpu-compositing works, but is not an option

tl;dr Fix:
I’ve created nvidia profile for code.exe and have set only one setting ( 0x10B135FE ) to 0x00000000. Issues is gone.

---

In NVIDIA Control Panel i have an option for Global profile set:
Background Application Max Framerate : 20

It works well for games(when ALT+TAB), and doesn’t affect Web Browsers (Chrome / Yandex ).
But it affects VSCode!

If i remove framerate limit, the issue is gone.

What makes Web Browsers special is NVIDIA Profiles.
Particulary one setting:

0x10B135FE is set to 0x00000000

If i remove or change it, then Web Browsers(tested on Yandex) starts to be much less responsive(like a vscode).
This setting seems like makes an app to ignore Background Application Max Framerate

maybe related: https://github.com/microsoft/vscode/issues/147253

side note:
i think VSCode must have its own profile, just because if User will set FXAA globally On, then you will see blurry text in VSCode but not in web browsers, since they have this(users are not able to change it in control panel):

other interesting settings:

Apart from testing the exploration builds, can you also check if launching code --disable-renderer-accessibility fixes the issue.

I’ve also seen that running code with --disable-renderer-accessibility makes Code scrolling work smoother. I’ve also assigned my GPU to render VSCode, but I’m not sure if that’s actually helping or it’s just placebo.

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 globally

Yu can just edit your code/code.cmd files to make VSCode always run with --disable-renderer-accessibility flag when running it from CLI (which I do a lot).

On Windows you can find these files in C:\Users\<user>\AppData\Local\Programs\Microsoft VS Code\bin and edit them like so:

# 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.

I do have this issue now too. I don’t think I had in any previous version. My observations:

• It’s fine when the file is small (50 lines is fine)
• File type did not matter, I had the issue in a lorem ipsum filled txt file
• Slow when all extensions are disabled, I coincidentally had to reinstall my OS (Windows 10) yesterday and the issue persists.
• I did a performance monitoring run while fast scrolling through a 700 lines file (lorem ipsum text) with extensions disabled and FPS dropped to 0 at some point. The results are here: https://gist.github.com/jonas-jonas/b0915211b146619cfbffeceed5deb117

Edit: My “about” information: Version: 1.49.0 (user setup) Commit: e790b931385d72cf5669fcefc51cdf65990efa5d Date: 2020-09-10T13:22:08.892Z Electron: 9.2.1 Chrome: 83.0.4103.122 Node.js: 12.14.1 V8: 8.3.110.13-electron.0 OS: Windows_NT x64 10.0.19041

Hope this helps!

As part of tackling 1) from https://github.com/microsoft/vscode/issues/107016#issuecomment-772509185, have backported https://chromium-review.googlesource.com/c/chromium/src/+/2720951 that fixes https://github.com/microsoft/vscode/issues/107016#issuecomment-697144210 and https://chromium-review.googlesource.com/c/chromium/src/+/2446089 which batches accessibility update events that usually block the renderer main thread.

Will update here with additional details once the build is available for testing.

I have been following this discussion for quite a while. Actually because I’ve blocked by VS Code version while waiting for a definitive fix to be used by my team.

An important question in my opinion: what is the technical reason for which some particular applications, such as Logitech Options or Oculus (cf. the above post) do influence an Electron app such as VS Code? Normally the OS + Electron + node.js should offer the developer a comfortable framework, where the dev doesn’t need to care about drivers and other low level stuff.

I observed this kind of strange “influencing” behavior also on other apps that seem to use Electron or similar as a “shell”. Skype is such a software. It doesn’t use Electron I guess, but it does use some have some wrappers so that the code runs on multiple types of OS.

The above question is important both as a VS Code user. But as a dev as well. Most of us use TS/JS. So maybe tomorrow we’ll develop some kind of app in Electron and customers will complain that because some odd third party software, our own code performs bad.

Any plans on adding --disable-renderer-accessibility to the argv.json file? --disable-gpu does nothing for me.

@deepak1556 code-insider with --disable-rendere-accessibility options shows much better scrolls both keyboard and wheel than before! Also, exploration build scrolls better than before but not better than disable-renderer-accessibility option. Finally, I’m not running windows on VM. It seems like disable-renderer-accessibility option is best workaround now.

I’m also noticing this issue, it seems to be caused by higher resolution, when I switch my monitor’s resolution from 3840x2160 to 1920x1080 I see an immediate speed up in VSCode

Let me know and I can provide more details

@alexdima from the above tests, looks like electron’s custom code isn’t forcing the accessible mode in this case.

we might want to look into adding Electron API such that we can disable it entirely and offer a flag or option for people experiencing problems with this to disable it completely

--disable-renderer-accessibility would be the flag.

@Minkyu-Choi when possible can you share another wpr trace for the exploration build https://github.com/microsoft/vscode/issues/107016#issuecomment-697727159

On Windows, I get a warning when I try to do disable-renderer-accessibility:

Warning: ‘disable-renderer-accessibility’ is not in the list of known options, but still passed to Electron/Chromium.

Double-checked and triple-checked the spelling.

This is expected, becauce it’s a chromium flag not a VSC flag. If renderer-accessibility is the cause of your issue, it should have been fixed after you passing the flag.

Hey I dunno if this deserves a seperate issue tracking, but after duplicating VSCode locally and messing around I was able to vastly improve scrolling and text selection performance on high-refresh monitors [anything above 60hz aka. below 16ms ]. Currently I’m looking to figure out how to commit this and do a pull request since it’s a really easy fix to an ancient 3 year old arbitrary 16ms delay between handling mouse events (dom.ts:298). However this does not change the performance cost of each frame, just allows the events to be handled quicker so the frame gets rendered faster.

On another note, it seems like the rendering framework that VSCode uses (viewLayer.ts) to me looks to be in a pretty sad state, given the rendering for both text and overlays first composes a string of HTML [first performance penalty] and then passes it over to the Chrome renderer to turn into actual DOM elements [second performance penalty]. Apparently according to https://github.com/microsoft/vscode/issues/106285#issuecomment-689414623 by @alexdima, supposedly the html string generation/parsing is faster than just creating the DOM elements directly? Intuitively the design choice doesn’t make a lot of sense to me, though I have yet to see a test comparing string generating/parsing to directly creating the DOM elements in javascript.

An intermediate solution to improving scrolling performance given the poor rendering techniques is to reduce the number of overlays rendered in the editor. By modifying settings.json, I found that disabling editor.renderIndentGuides and editor.lineNumbers respectively gave the best performance improvements, with some smaller gains from disabling editor.glyphMargin, editor.folding, scm.diffDecorations, editor.minimap.enabled. With everything disabled my cost per-frame of scrolling to a completely new section of a file went from ~65ms down to ~25ms. Ultimately these features should stay enabled and the base performance should improve with code refactors.

I’ve been struggling with the performance issue recently on Windows 10 x64.

code --disable-renderer-accessibility . works for me. Scrolling and typing is now back to buttery smooth without disabling any running extensions.

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.

I believe I’ve found a reliable way to reproduce this issue (on my computer at least):

• Open VSCode
• Open Spotify (the Windows store app)
• Start playing music in Spotify
• Minimize Spotify and focus back on VSCode
• Press the “pause” media key on my keyboard to pause Spotify while it is minimized
• VSCode scrolling is now quite laggy
• Restarting VSCode or Spotify does not fix the issue. Restarting Windows does fix the issue, until I repeat the above steps.

---

Others who have reported this issue, please confirm the following

• Does running with --disable-renderer-accessibility help improve the perf ?
• What is the output of running #107016 (comment)
• Is the exploration build #107016 (comment) any better in perf ?

• Yes, --disable-renderer-accessibility makes it significantly better
• 0
• Yes

---

Other Info about my computer:

• VSCode version: 1.51.1
• Windows version: Windows 10 Pro version 20H2 build 19042.685
• Touchscreen: Yes
• Windows running in a VM: No
• Computer supports tablet mode: Yes
• Computer was in tablet mode at the time the issue occurred: No
• Logitech Options application installed: Yes

Same issue --disable-renderer-accessibility fixed the issues, thansk for this command, btw. --disable-gpu also can fix the isssue. So looks like this is GPU render issue related.

–disable-renderer-accessibility did not work –disable-gpu solved my problem

Version: 1.68.1 (system setup) Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630 Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0.19043

Running on fusion.

I had the same behaviour on linux (Xubuntu 20.04 LTS) - slow vscode scrolling and typing, along with some other oddities like a slight flicker on the screen (system wide, not just vscode). I also have a 144Hz display, not sure if that matters since I also saw it in 60 Hz mode.

It seems to have gone away if I go to “Window Manager Tweaks” -> “Compositor” and un-click “enable display compositing”. My display now “feels” like it’s in 144Hz mode and all the jerky vscode behaviour is gone.

@jjiburg please open a new issue for macOS, I am tracking this issue specifically for windows.

Oh wow, the --disable-renderer-accessibility workaround is like night and day for me! I’ve been getting so frustrated with how unusable vscode has become for me with how laggy everything is.

In my case I realised today that it’s the Oculus app on my system that’s the trigger for this issue. If I open VSCode before opening the Oculus app then there’s no input lag but as soon as the app opens up then all running instances of vscode basically become unusable for me. (That’s a pretty big problem for me since I’m developing a VR application! 😃 )

I had recently upgraded the machine with an additional 16GB of RAM, to 32GB due to this issue because the only thing I could think of previously was that my system was using a lot of RAM and maybe I was getting tipped over a cliff and hitting virtual memory on disk - that didn’t make a difference here though. Since then, investigating why vscode was so laggy it seemed odd that there was no obvious resource limit being hit on my system (cpu usage, memory, disk io etc all seemed reasonable).

The strange thing with opening up the Oculus software is that VSCode remains unusable even after closing the Oculus software but if I re-open VSCode while the Oculus software is closed then it’s fine. That’s what essentially led me to try out this workaround since it clearly wasn’t just an issue of the Oculus app competing for resources.

Since the --disable-renderer-accessibility workound seems to resolve this long-standing performance problem for me I guess, from the discussion above, that the way the Oculus app/drivers work they somehow present as some kind of accessibility technology which confuses Chromium into entering accessibility mode.

No doubt I’m far from the only VR dev using VSCode so in case anyone else has been struggling a lot with input lag you might want to try launching with code --disable-renderer-accessibility too until there’s a proper fix for this!

I’m sooo happy right now that this workaround works - hard to overstate how unusable vscode has been with this issue!

@rzhao271 No, editor.accessibilitySupport does not have any effect on Electron.

Just another confirmation that on vscode 1.52.1 launching with --disable-renderer-accessibility fixes dramatic slowdown for me.

Hi all - just want to confirm on Windows 10 (v1809) that running vscode with --disable-renderer-accessibility has dramatically increased scroll performance for me especially on larger files.

Downgrading to 1.48.2 also solved the issue for me.

if you have a laptop try to change vscode from using gpu to cpu, worked for me

I’m currently having this problem with a roughly 28-page markdown file.

Version:

❯ code-insiders --version
1.70.0-insider
3104db414c8fedcf6e4493f14da7df0b7413853a
x64

@kamenminkov thanks for the heads-up, I’ll try the new version then see if it works on my side as well

I think it’s possible that this is a Windows bug and not a VSCode bug. Latest Windows Insiders build’s release notes mention fixing of a stuttering problem and that seems to be the case indeed - I haven’t seen the bug since I upgraded to that build.

I’ve had kind of similar issues - but maybe not to such extent - sometimes when I enter full screen, scrolling and text input becomes somewhat choppier - not to the extent of being unusable, but it’s noticeable. It’s not all the time, but unfortunately I can’t pinpoint what’s causing the problem. It’s been happening on both my current machine (Ryzen 9 5900X, 16 GiB RAM, GTX 1080, two displays) and previously on the same machine with a different CPU and motherboard (an i7-5820K and also temporarily an i7-3770) - all that on the latest Windows 10 Insiders (Dev channel - I usually update to the latest build every week or every 2 weeks). I haven’t noticed problems on Pop!_OS 20.04 and later on 20.10 (dual boot on the very same machine, just different SSD).

Starting with the flag --disable-renderer-accessibility doesn’t seem to make a difference.

What stood out to me is that exiting full screen (even if I use the same maximised window) immediately solves the problem.

@TacticalDan It makes sense to me that disabling line numbers and indent guides leads to faster renderings, but I’ve also noticed in the past that the Performance tab can grossly inflate numbers (sometimes doubling them), especially around setTimeout/clearTimeout, which we use plenty of.

So to get a closer picture to real life, I often go to the gear icon and “Disable JavaScript samples” and I also disable Screenshots:

“Disable JavaScript samples” & “Disable Screenshots”	Regular Profile

That being said, there is nothing jumping in my face from your screenshots, so there doesn’t appear to be anything incredibly slow. There is one thing I think we need to do soon and that is to adopt shadow dom for the editor. The vscode workbench has a gazillion CSS rules and they all make “Recalculate style” a whole lot slower than it needs to be, but otherwise there is nothing actionable that I can think of right now. If you have ideas about how to speed things up, I would love to talk about that. I also think that those indent guides could be easily drawable via <svg> but I never really tried it.

--disable-renderer-accessibility did make fps when scrolling become 10-30 fps, without code --disable-renderer-accessibility fps is around 0-5 fps

Strangely, installing the update to 1.52.0 temporarily fixed the issue, but as soon as I go through the reproduction steps in https://github.com/microsoft/vscode/issues/107016#issuecomment-720136991 or https://github.com/microsoft/vscode/issues/107016#issuecomment-742872953 the issue returns. --disable-renderer-accessibility still appears to work as a workaround.

An easy way to reproduce this issue on windows 10 is to open the built-in windows on-screen keyboard

@RLesma just to double check: sometimes, if there is a vscode instance running, running code on the command line will not start a new instance of vscode, it will just talk to the running instance and ask it to open a new window. So the test would be to be sure (via Task Manager if necessary) that no code instances are running when you are trying out the command line flag.

Oh, you were completely right! closing all the instances and then starting it up with the --disable-renderer-accessibility flag solved the issue! The performance improved dramatically! Thank you for the tip! I thought that the new instance would have the flag set, even if I had other instances open.

Is there any way to set this flag by default in a link? I have to investigate this, not to have to open the shell all the time