Slow reponse to scroll and typing

[RLesma]

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 (58bb7b2331731bf72587010e943852e13e6fd3cf, 2020-09-16T23:27:51.792Z) OS version: Windows_NT x64 10.0.19041

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (4 x 2712)| |GPU Status|2d_canvas: enabled
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| |Load (avg)|undefined| |Memory (System)|11.85GB (4.20GB free)| |Process Argv|--crash-reporter-id 2c01e348-504e-456f-931c-280aa8926a03| |Screen Reader|no| |VM|0%|

Process Info

``` CPU % Mem MB PID Process 2 96 33588 code main 2 88 13340 shared-process 3 84 26656 window (Issue Reporter) 0 24 27836 crashpad-handler 0 223 30908 window (Settings - local_svn_workspace (Workspace) - Visual Studio Code) 0 11 6640 watcherService 0 6 12092 console-window-host (Windows internal process) 0 6 9240 console-window-host (Windows internal process) 0 96 19504 extensionHost 0 69 30740 C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe 0 60 30924 utility 1 241 33368 gpu-process ```

Workspace Info

``` | Window (Settings - local_svn_workspace (Workspace) - Visual Studio Code) | Folder (JESD204): 1760 files | File types: svn-base(998) v(161) sv(38) sh(33) tcl(30) prj(30) do(25) | tmp(9) txt(9) log(7) | Conf files: makefile(7); ```

Extensions (11)

Extension|Author (truncated)|Version ---|---|--- better-comments|aar|2.1.0 bracket-pair-colorizer|Coe|1.0.61 ctags-support|jay|1.0.19 svn-scm|joh|2.12.4 rainbow-csv|mec|1.7.1 remote-ssh|ms-|0.55.0 remote-ssh-edit|ms-|0.55.0 remote-wsl|ms-|0.44.5 veriloghdl|msh|1.3.3 awesome-vhdl|puo|0.0.1 tcl|ras|0.1.0

[rib]

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!

[cristian-spiescu]

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.

[alexdima]

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.

Here is what I know on the topic.

1. Chromium is slow in "accessibility mode"

In order to support Screen Readers, Chromium renderer processes enter a special "accessibility mode" which ends up building a parallel accessibility tree which is extracted (using aria- properties) from the DOM. This accessibility tree must be kept in sync (or fetched as needed) between the Chromium renderer process and the Chromium main process which handles OS events. This accessibility tree is not created/maintained/synced normally, but only when a Screen Reader is attached to Chromium and the renderer enters this special "accessibility mode". For whatever reason, the Chromium renderer process becomes incredibly slow when it needs to maintain this accessibility tree. I don't understand why, since the accessibility tree is just a small subset of the entirety of the DOM. This should definitely be improved by Chromium, and @deepak1556 has provided Chromium with a simple repro case, but in my experience, Chromium has been 3x - 5x slower since 5+ years when entering accessibility mode, so I personally don't think that this gets fixed by us adding some background color to one of the DOM nodes. For example, from past experiments, problems immediately appear when having a single <textarea> with 50000 characters and attaching a screen reader. The screen reader glitches out because Chromium does not reply to it within a decent amount of time.

2. Starting with Electron 9 (Chromium 83), Chromium enters accessibility mode much more easily

The problem in Windows is that the OS does not give straight-forward API to tell your application when a Screen Reader is attached. From what I know, the clue was always in some WM_GETOBJECT that would be sent from the Screen Reader to the current active window. The last time I saw this exact problem, it used to be that Electron would be entering accessibility mode when having a laptop with a touch screen. But that time the problem was in Electron, which would force Chromium into accessibility mode.

It looks like the problem now is that Chromium itself decides to enter accessibility mode. So I think these other applications that folks keep finding (like e.g. Oculus software, the Logitech mouse, possibly the built-in touch keyboard) very likely send a WM_GETOBJECT to the active VS Code Window and that looks very similar to how a Screen Reader message would look like, and that drives Chromium to enter the accessibility mode.

---

@deepak1556 I see that you drive very well the first problem (to improve the speed of Chromium once it is in accessibility mode). But is there anything we can do to stop from falsely entering accessibility mode? For example, I doubt that the real Chrome is entering accessibility mode, as all of these folks would have a horrible browsing experience (3x-5x slowed down).

[mabasic]

This issue started for me when I toggled smooth scrolling on/off in logitech options.

It seems to be resolved now.

[cristian-spiescu]

Wow! Thanks @alexdima for this precious feedback. In my opinion, it should stay in some kind of doc of Electron. We actually have plans of publishing our app also as a Electron app (besides web and Cordova), and it's very probable that we'd fall into this pitfall.

[schroef]

I tried it once more after noticing i also had put wrong path in the json file

So did the file get generated at the path after you had quit the app ?

You can safely ignore that warning, it just means vscode doesn't understand the flag but will pass it down to chromium for further processing. And yes it is only used for debugging in chromium, most of the chromium apps use a gui version of this, so won't find much usage in public.

@deepak1556 sorry for the delayed response. No i didnt not get it to work. I tried many options but perhaps im using wrong paths. You initial argument you showed a path i dont have. My VSC is in programs 32 not programs. That file is not in the other folder neither. I changed it to the json i created and saved on the desktop but nothing appears when quiting VSC insiders.

[schroef]

I tried once more just now. For clearance im using this method to get it to run. I start CMD and drag the app icon into it than i add your comment with my adjusted path address. So i get this

C:\Users\romboutversluijs>"C:\Users\romboutversluijs\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Visual Studio Code - Insiders\Visual Studio Code - Insiders.lnk" --trace-config-file="C:\Users\romboutversluijs\Desktop\trace.json"

then in the json file i fot this address for the log. Ill try another run with double backslashes, im not sure this is correct, in other languages a backslash needs to be commented out.

"C:\Users\romboutversluijs\Desktop\chrometrace.log

[schroef]

Had another run with the original app exe. This time when i drop it in CMD VSC seems to become responseless, i get almost complete blank window. Yet task manager does not state anything wrong with the app.

EDIT after typing this message and checking back at the app, it seems it came to life. Took like 3-5 minutes or so before GUI appears as it should be. Then tried opening a file and app crashes, it gave a warning. Then the window is blank as seen above.

I also tried adding the argument to the app startmenu icon. Same thing happens, i end up with almost blank window and takes forever to show the GUI

[apasashkov]

Have the same issue on brand new machine.

HARDWARE: Ryzen 5900x (10% utilization) RAM 32Gb (12gb used)

SOFTWARE: Version: 1.52.1 Commit: ea3859d Date: 2020-12-16T16:32:10.090Z Electron: 9.3.5 Chrome: 83.0.4103.122 Node.js: 12.14.1 V8: 8.3.110.13-electron.0 OS: UBUNTU 20.04 kernel: Linux x64 5.8.0-41-generic

Any other app works smoothly (chrome, firefox, slack, libreoffice etc)

Tried restarting in dev mode with extensions OFF - same situation.

Dev console - 1 error related to the project, 99% sure not related to the issue (have the same error on different machine and no lagging). Also, on different machine have older hardware (i7 6700 + 16gb ram) + older software (ubuntu 18.04 kernel 4.15). Same workload. Same VS code version - works much more smoother.

EDIT: Spent several hours looking inside this thing. Appears that updating to the latest NVIDIA driver fixes things up.

[jjiburg]

@deepak1556 I see that this issue is described as "Scroll performance on Windows" in the Feb 2021 iteration plan. Should I open a new issue for scroll performance on macOS or do you believe the issue is related?

More info in my previous comment:

https://github.com/microsoft/vscode/issues/107016#issuecomment-766952769

I've encountered this degraded performance issue on macOS Big Sur, it appears that launching vscode with the --disable-renderer-accessibility flag resolves it.

I'm attaching two performance profiles in a zip. One run with the flag enabled and smooth scrolling performance and the other with no cmd args passed and poor performance.

vscode accessibility performance.zip

[deepak1556]

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

[kamenminkov]

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.

[schroef]

I just noticed a little detail. When you work with a dual monitor setup and your focus is on the other monitor, normally you need to focus on the main monitor to set the focus. However when you have focus on monitor 2 but then start scrolling on monitor 1 with VSC active, the scrolling is super smooth! Scrolling is much more responsive when VSC is not in focus.

This is on a Omen 15 Ryzen 7 4800H, 1660Ti

This is how it should work

PS why is this issue closed, i dont see a fix in 1.54.1?

[kamenminkov]

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.

[schroef]

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

[schroef]

@kamenminkov just tried it and Insiders and dont see any difference actually, its still sluggish

Same goes here as with 2 monitors. Opening insiders and main version then having insiders in focus but hover over the main version. Scrolling is butter smooth then

[deepak1556]

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.

[thebruce87m]

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.

[reinux]

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.

[SeanChao]

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.

[pedia]

Disable "Notebook: Line Number" maybe improve performance of scrolling.

After disable "Line Number":

Version: 1.57.1
Commit: 507ce72a4466fbb27b715c3722558bb15afa9f48
Date: 2021-06-17T13:28:32.912Z (3 wks ago)
Electron: 12.0.7
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: 8.9.255.25-electron.0
OS: Darwin x64 20.1.0

[Saugatkafley]

This fixed my issue ,

Ctrl + Shift + P,

Preferences , Reload with extension disabled . VS was still buggy and slow to use. Then I again reload it fixed the issue

[BlueDev5]

This fixed my issue ,

Ctrl + Shift + P,

Preferences , Reload with extension disabled . VS was still buggy and slow to use. Then I again reload it fixed the issue

This also helped me, and vscode didnt lag even after closing the window and re-opening it

[LittleFishLove]

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

Could you please paste a link of the macOS solution?

[hsyhsw]

Sorry. Just posting this here since there seems to be no Mac specific tickets available right now. (all closed without satisfying solution)

Following tickets and comments for the Macs: https://github.com/microsoft/vscode/issues/99387#issuecomment-685111432 https://github.com/microsoft/vscode/issues/104335#issuecomment-671166130 seem to be some kind of incompatibility issue with Electron + certain profile type, not the color profile itself. I had the same issue for my old(mid 2012) MBP, thinking that it's time to dump this old, slow machine.

Today the issue has completely gone not completely, but vscode now runs considerably faster after applying a new color profile of type 'single curve + matrix', not 'xyz lut + matrix'. (yay! my mac is live again!) Actually got a hint from displaycal warning saying native MacOS does not support profiles other than single curve + matrix. I think it's worth trying creating a new profile of a proper type if you are using one made some time ago.

[mbevilacqua]

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

[mjspeck]

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

Version:

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

[Befzz]

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:

[YinanZhaoXometry]

this fix my input lagging issue, only in markdown files

[rynoV]

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

[LucaMarconato]

For me setting editor.hover.delay to 20 (it was 10), helped.

[kurtextrem]

An easy fix is to add the vscode binary to the Google Chrome nvidia profile. This automatically applies all hidden settings in the nvidia profile to it.

[notmalicik]

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

[rynoV]

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

Thanks! With code --disable-renderer-accessibility --disable-gpu I saw an improvement even at high resolution, although there's still a bit of lag but that could be something else

I think I tried this before, but I may not have completely closed vscode before running with the new flags

[tadghh]

Other launch options for future lurkers vscodium.cmd --disable-gpu --disable-software-rasterizer --disable-http2 --disable-http-cache --force_low_power_gpu --use-gl=egl

[iacullo-atri]

--disable-renderer-accessibility by itself fixed my scrolling issues.

[JHartzer]

Another data point: code-insiders --disable-renderer-accessibility resolved these issues for me as well

[nathanredblur]

My vscode is very slow when you move the cursor with keys from left to right. I try to investigate why, but this beats me.

https://github.com/user-attachments/assets/cc1d0715-96d2-42d5-abfc-e544ce258eb1

[tadghh]

My vscode is very slow when you move the cursor with keys from left to right. I try to investigate why, but this beats me. CleanShot.2024-08-01.at.21.53.06.mp4

Could be caused by Nvidias power saving "WhisperMode/BatteryBoost" feature. It limits the fps to 30 even on Windows balanced power profile.

[MarFre22]

Thanks for all your tips! Although I use VSCodium on Mac, I followed the ones recommended by @iacullo-atri @tadghh @JHartzer @rynoV and it worked very well!

I've also made a customised shortcut, in AppleScript, which makes it possible to run with the aforementioned arguments (I used (--disable-gpu --disable-software-rasterizer --disable-http2 --disable-http-cache --force_low_power_gpu --use-gl=egl) via the Dock, Launchpad or Spotlight and via a file ("always open with..."). In practice, I don't need to use the original shortcut.

Only Compatible with MacOS, tested on Sonoma version 14.5. It should be compatible with VSCode, you just need to change /Applications/VSCodium.app/Contents/Resources/app/bin/codium (blank space at the end!).

I hope it helps someone!

AppleScript code below, use the Script Editor and save as an app.

on open fileList
    -- Execute when the application is started from a file (by finder)
    repeat with aFile in fileList
        set filePath to POSIX path of aFile
        do shell script "/Applications/VSCodium.app/Contents/Resources/app/bin/codium " & quoted form of filePath & " --args --disable-gpu --disable-software-rasterizer --disable-http2 --disable-http-cache --force_low_power_gpu --use-gl=eg"
    end repeat
end open

on run
    -- Execute when the application is launched from the Dock/Spotlight (without any files)
    do shell script "/Applications/VSCodium.app/Contents/Resources/app/bin/codium --args --disable-gpu --disable-software-rasterizer --disable-http2 --disable-http-cache --force_low_power_gpu --use-gl=egl"
end run