Slow reponse to scroll and typing

RLesma commented 3 years ago

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

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

isuke01 commented 3 years ago

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.

JoseluGames commented 3 years ago

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

jose-verissimo commented 3 years ago

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

@JoseluGames I had to add it in the properties and restarted the whole application then it worked for me. BTW I only added --disable-renderer-accessibility

perholmes commented 3 years ago

Also confirming that with --disable-renderer-accessibility, scrolling frame rate when from 1-10 FPS up to 60 FPS.

CosmicBagel commented 3 years ago

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) launching with --disable-renderer-accessibility massively improves the performance

VS Code version: 1.51.1 Windows 10 20H2 (19042.630)

dylanwulf commented 3 years ago

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

mj-crabtree commented 3 years ago

updating to 1.52.0 appears to have resolved the issue on my end. i can now launch vscode from the start menu, from the terminal, and from an AHK script, all without using --disable-renderer-accessibility, and scrolling through thousands of lines feels just fine.

update: after almost a week of code working just fine it's gone back to stuttering when scrolling through large files. --disable-renderer-accessibility resolves the issue.

perholmes commented 3 years ago

1.52.0 does NOT resolve the problem here. Removing --disable-renderer-accessibility, I'm back to a solid 5-10 fps.

dylanwulf commented 3 years ago

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.

motss commented 3 years ago

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.

markeissler commented 3 years ago

The use of --disable-renderer-accessibility doesn't appear to work if launching this from within Ubuntu (for example) running in WSL2. I get this:

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

SeanChao commented 3 years ago

The use of --disable-renderer-accessibility doesn't appear to work if launching this from within Ubuntu (for example) running in WSL2. I get this:
$ 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

mabasic commented 3 years ago

I was almost going to switch to a different IDE and/or reinstall OS xD before finding out this issue..

Update: Adding --disable-renderer-accessibility, then starting vs code from Windows, then navigating to WSL2 directory. VS code seems to work a bit faster, but it still lags on scroll and sidebar toggle...

relliv commented 3 years ago

--disable-renderer-accessibility not effected any thing. I tried every setting and combination but it is not working stable.

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.

azmiadhani commented 3 years ago

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

mzandvliet commented 3 years ago

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

schroef commented 3 years ago

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.

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

seanmortimer commented 3 years ago

code --disable-renderer-accessibility Gives me:

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

What am I doing wrong?

dylanwulf commented 3 years ago

@seanmortimer

What am I doing wrong?

Nothing, mine does that too. Even with the warning it still seems to work for me.

gencer commented 3 years ago

code --disable-renderer-accessibility Gives me:

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

What am I doing wrong?

You're not doing anything wrong. It ain't supported. But it will by subprocess. Just ignore it.

azmiadhani commented 3 years ago

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.

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

Add it on shortcut after .exe or you can simply type in cmd code --disable-renderer-accessibility

seanmortimer commented 3 years ago

@dylanwulf, @gencer Thank you. Indeed, running code --disable-renderer-accessibility from powershell totally fixes the scroll lag for me. Interestingly, the same command from the Ubuntu command line in WSL doesn't fix it.

alexdima commented 3 years ago

@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??

jonlepage commented 3 years ago

Never open MicrosoftVirtualKeyboard in your current Window sessions. 😂 here proof in video with vscode huge file. https://youtu.be/14AKtLqlbtE Thas mean check all background software in your machine, they can break vscode. like: Mouses macro softwares, (Logitech options on my side is fine) Keyboards macro softwares. (Redragon K580RGB Keyboard for me is fines)

the irony is the offending keyboard software is developed by Microsoft. the other one not break Vscode ! so this mean even on a fresh install OS, Windows could have native processes or app that will break Microsoft Vscode!

--- EDIT i just want add a hint, i also dev with nwjs based on chromium like electron, and since i get sometime weird ghost laggy memory leak app. When this happened vscode was very laggy (lethargy state). https://youtu.be/NNVjv-cPzvk It could be that this is also related to chromium and the problem is related to the use of external accessibility softwares or process. Its can cause serious damages to an SSD and Ram I guess when vscode goes into this lethargy state to link an outside program accessibility from chromium, it doesn't handle or break the debugging system or command well and keeps sometime children app alive ! and those need to be kill manually!

dvdvnl commented 3 years ago

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

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.

rzhao271 commented 3 years ago

There is a setting editor.accessibilitySupport within VS Code and it can be switched to off. I wonder if that works instead of having to pass in --disable-renderer-accessibility every time?

alexdima commented 3 years ago

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

lesmo commented 3 years ago

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.

IgorKrupenja commented 3 years ago

A way to reproduce this with macOS:

Install Vimac https://vimacapp.com/
Open VSCode

Scrolling is sluggish. Quitting Vimac or running with --disable-renderer-accessibility solves the issue.

jjiburg commented 3 years ago

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

Nathan-Franck commented 3 years ago

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.

Nathan-Franck commented 3 years ago

Apparently according to #106285 (comment) by @alexdima, supposedly the html string generation/parsing is faster than just creating the DOM elements directly?

After creating a test at https://codepen.io/tacticaldan/pen/KKgjLNe - it does look as though the method used in viewLayer.ts is better compared to creating the DOM elements manually in javascript. It feels pretty counter-intuitive but I guess the Chrome renderer is pretty well practiced at parsing HTML strings 🤔 makes sense I guess.

alexdima commented 3 years ago

With everything disabled my cost per-frame of scrolling to a completely new section of a file went from ~65ms down to ~25ms.

That does not sound right. Can you reproduce this also in Chrome with https://vscode-web-test-playground.azurewebsites.net/ ? How about a non-Chromium browser like FF or Safari? What OS are you on?

Nathan-Franck commented 3 years ago

Here you go - first with overlays: For dev - With all overlays Now with settings.json on { "editor.renderIndentGuides": false, "editor.lineNumbers": "off", "editor.glyphMargin": false, "editor.folding": false, "scm.diffDecorations": "none", "editor.minimap.enabled": false }: For dev - With no overlays

For my test I took a really long generated SDL-header-converted-to-json file and scrolled as hard as I could with the scrollbar for maximum performance cost.

This is running on Windows 10 with a Ryzen 1800x CPU. I haven't tried Firefox yet, but I'm mostly concerned about Electron performance so I'm testing in Chrome.

Nathan-Franck commented 3 years ago

Side by side on large

Here's a scrollbar shaking test [scrolling as fast as possible up and down], where overlays are disabled on the left and enabled on the right, I'm using the large.ts file instead of my custom file, still getting really great improvement by disabling overlays. I didn't cherry pick frames with GC or anything, this is average.

alexdima commented 3 years ago

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

deepak1556 commented 3 years ago

We landed a fix in the runtime that increases the stack size on windows which has a side effect of improving this scroll lag situation. Can anyone test on windows with the latest insiders https://code.visualstudio.com/insiders if the scroll is better ? Thanks!

schroef commented 3 years ago

@deepak1556

just test tested insiders version. I dont see a difference vs latest v1.52..1 Long files arent that smooth. Im using a wacom tablet. Scrolling with minimap is okay. All smooth animation are OFF. i dont see any difference using start with --disable-renderer-accessibility

using Windows 10 20h2 Omen 15 16 RAM Ryzen 4800h Gforce 1660Ti

Nvida control panel is set to auto.

At the office running OSX 10.11.6 scrolling is better using same tablet. Though its not lagging, it feels sluggish and sometimes feels like it lagging or sticky. I need to scroll more to get it moving more, not sure im explaining it properly. Its not as smooth as Chrome for instance

deepak1556 commented 3 years ago

Thanks for checking @schroef , can you follow the steps at https://github.com/microsoft/vscode/issues/106939#issuecomment-695904826 and send the traces.

schroef commented 3 years ago

@deepak1556 sorry but i dont seem to have that app, it doesnt show up for me

schroef commented 3 years ago

nevermind, my search is messed up. found it in c://Windwos/system32/wpr.exe, still getting used to windwos after 17yr mac only

schroef commented 3 years ago

sorry but it wont run, i see sort of a window flashing for like 100 of mil second thats it. run as admin same deal

lesmo commented 3 years ago

We landed a fix in the runtime that increases the stack size on windows which has a side effect of improving this scroll lag situation. Can anyone test on windows with the latest insiders code.visualstudio.com/insiders if the scroll is better ? Thanks!

I tried today's build. For me, it got worse :(

Maybe "smoothness" hasn't changed, but "input lag" exists now. It takes quite some time (some ms, probably exaggerating tho) for my touchpad scroll to actually scroll on VSCode. I tried setting it up with almost the same extensions and settings (was thinking on making it my daily driver) as my regular VScode.

I've also tried running VSCode Insiders with --disable-renderer-accessibility but same result. I've also assigned VScode on Windows' Graphics Settings to my Nvidia card and same thing. Maybe not necessarily a UI performance issue?

My regular VSCode install is even "modded" with the Vibrancy extension (for acrylic window transparency through an odd hack) and it's still smooth and more responsive than VSCode Insiders build (which I didn't install this extension to because it's broken on it, but that's another story).

By any chance anyone else is experiencing this "lag" on Insiders? It would be a real shame to see this fix released and make things worse :(

Nathan-Franck commented 3 years ago

We landed a fix in the runtime that increases the stack size on windows which has a side effect of improving this scroll lag situation. Can anyone test on windows with the latest insiders https://code.visualstudio.com/insiders if the scroll is better ? Thanks!

I'm seeing an improvement of ~10% on my really scroll heavy tests, so definitely an improvement I think! Not feeling any difference with input lag [Windows 10, Ryzen 1800x]

Nathan-Franck commented 3 years ago

Insider improvements

On closer inspection I'm regularily seeing from ~45 ms down to ~35 ms so more than 20%! Nice boost 😁

deepak1556 commented 3 years ago

@lesmo @schroef can you try these steps to get a runtime trace,

Create trace.json somewhere on your disk with the following content:

{
"result_file": "<some-absolute-path>\chrometrace.log",
"trace_config": {
"record_mode": "record-until-full",
"included_categories": [
 "blink",
 "browser",
 "io",
 "latency",
 "ipc",
 "benchmark",
 "gpu",
 "cc",
 "toplevel",
 "viz",
 "v8",
 "disabled-by-default-v8.ic_stats"
],
"excluded_categories": ["*"]
}
}

Start code-insiders --trace-config-file="C:\Program Files\Microsoft VS Code\trace.json"
Use the editor as normal and ensure the slowdown is seen
Quit the editor
Attach the generated chrometrace.log

schroef commented 3 years ago

i used cmd to run code inside with the argument. I got this warning and also dont see any log file. i did change this line ```Start code-insiders --trace-config-file="C:\Program Files\Microsoft VS Code\trace.json"```` to the path of that json file i had to make since that path doesnt excist on my system.

after a second run, i noticed i made a mistake in that path. When i corrected it to the path of that json file, vsc insider crashes instantly

(electron) Sending uncompressed crash reports is deprecated and will be removed in a future version of Electron. Set { compress: true } to opt-in to the new behavior. Crash reports will be uploaded gzipped, which most crash reporting servers support.
Warning: 'trace-config-file' is not in the list of known options, but still passed to Electron/Chromium.
[main 2021-02-02T01:20:12.689Z] update#setState idle
(node:13888) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
(node:13888) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
(node:5624) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\romboutversluijs\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
[main 2021-02-02T01:20:42.709Z] update#setState checking for updates
[main 2021-02-02T01:20:43.327Z] update#setState idle
[main 2021-02-02T01:20:44.034Z] Main: detected unresponsive
[main 2021-02-02T01:20:50.164Z] Main: renderer process crashed (detail: crashed)
[main 2021-02-02T01:21:01.058Z] Main: renderer process crashed (detail: killed)
[main 2021-02-02T01:21:01.148Z] SharedProcess: crashed (detail: killed)

this is vsc insider version, downloaded last week

Version: 1.53.0-insider (user setup)
Commit: 565dc9704f27619ad73867fddde6bbca88110c18
Date: 2021-02-01T16:49:24.403Z
Electron: 11.2.1
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Windows_NT x64 10.0.19042

schroef commented 3 years ago

I tried it once more after noticing i also had put wrong path in the json file. I corrected that, but still i get the warning about the argument not being in the list

C:\Users\romboutversluijs>
(electron) Sending uncompressed crash reports is deprecated and will be removed in a future version of Electron. Set { compress: true } to opt-in to the new behavior. Crash reports will be uploaded gzipped, which most crash reporting servers support.
Warning: 'trace-config-file' is not in the list of known options, but still passed to Electron/Chromium.
[main 2021-02-02T01:40:45.658Z] update#setState idle
(node:13748) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
(node:7188) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\romboutversluijs\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar.unpacked\vscode-sqlite3\build\Release\sqlite.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:7188) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\romboutversluijs\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:13748) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
(node:1076) Electron: Loading non-context-aware native module in renderer: '\\?\C:\Users\romboutversluijs\AppData\Local\Programs\Microsoft VS Code Insiders\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
[main 2021-02-02T01:41:15.666Z] update#setState checking for updates
[main 2021-02-02T01:41:15.787Z] update#setState idle

I also cant seem to find anything related on google using that argument?

schroef commented 3 years ago

I did found this for that trace-config-file, something chromium related. https://chromium.googlesource.com/chromium/src/+/66.0.3359.158/components/tracing/common/trace_config_file.h

deepak1556 commented 3 years ago

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.

microsoft / vscode

Slow reponse to scroll and typing #107016

How to edit Code CLI arguments globally