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,
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! |
|
Disable "Notebook: Line Number" maybe improve performance of scrolling. After disable "Line Number": |
|
This fixed my issue ,
Preferences , Reload with extension disabled . |
This also helped me, and vscode didnt lag even after closing the window and re-opening it |
Could you please paste a link of the macOS solution? |
|
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:
|
|
--disable-renderer-accessibility did not work Version: 1.68.1 (system setup) Running on fusion. |
|
I'm currently having this problem with a roughly 28-page markdown file. Version: |
|
i'am able to pinpoint issue for my PC (win10 19043 x64 / NVIDIA 1060) issue: scrolling seems like lagging behind, app behave not responsive tl;dr Fix: In NVIDIA Control Panel i have an option for Global profile set: It works well for games(when ALT+TAB), and doesn't affect Web Browsers (Chrome / Yandex ). If i remove framerate limit, the issue is gone. What makes Web Browsers special is NVIDIA Profiles.
If i remove or change it, then Web Browsers(tested on Yandex) starts to be much less responsive(like a vscode). maybe related: #147253 side note: other interesting settings: |
|
|
|
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 |
|
For me setting |
|
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.
|
|
if you have a laptop try to change vscode from using gpu to cpu, worked for me |
Thanks! With I think I tried this before, but I may not have completely closed vscode before running with the new flags |
|
Other launch options for future lurkers |
|
|
|
Another data point: |
|
My vscode is very slow when you move the cursor with keys from left to right. 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. |
|
Thanks for all your tips! I've also made a customised shortcut, in AppleScript, which makes it possible to run with the aforementioned arguments (I used ( Only Compatible with MacOS, tested on Sonoma version 14.5. 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 |
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: