Vscode: Add a setting to disable gpu acceleration

[SpaceShot]

• VSCode Version: 1.7.1-1478180561
• OS Version: ubuntu 16.04 LTS
  more info:
  Guest OS using VM on VirtualBox 5.0.26,
  Guest Additions installed,
  unity_support_test reports Unity 3D supported = yes (everything is lit up with green yes)

Steps to Reproduce:

1. Start VSCode. This can be when docked in Launcher or launched via GUI or launched from command line
2. Window appears, screen stays black. There might be grey rectangles or a blinking cursor, moving the window usually results in tearing.

Workaround
Launch from command line with code . --disable-gpu
If first window is launched this way, subsequent windows launched by any method follow option of currently open window(s)

Proposed Workaround
Once I identify that this machine can't run VSCode effectively without --disable-gpu, can we have a way to add to settings.json and be done with it?

Thank you for consideration

[SpaceShot]

Forgot VS Code version (sorry). -fixed-

[bpasero]

@SpaceShot are you saying that you see the first window with GPU disabled but subsequent windows are not?

[bpasero]

There is app.disableHardwareAcceleration, but it needs to be set very early.

[SpaceShot]

My proposal is that it would be nice to not have to set this every time from the command line because I know for this configuration (OS and guest VM) I have to run with --disable-gpu

As a minor complaint, this also means docking Code in the launcher is somewhat pointless because I need to go to terminal and use the --disable-gpu option.

I simply was adding more information that I tried a few things, such as opening with --disable-gpu and then seeing what happened if I opened more windows.

[billscheidel]

I have the same configuration and disabled the gpu in a similar manner. But now I'm seeing really bad screen tearing on scroll. Basically every time I scroll, I need to stop scrolling then scroll a little bit up or down to refresh the ui and fix the issue. Is there any way to fix this?

[faustotnc]

I'm having to do the same. Otherwise, VSCode won't respond until 0.6/2 seconds after performing any action like typing, scrolling or even opening small files (20 - 40 lines).

I know that opening the terminal, typing code --disable-gpu, and pressing enter seems like a really small set of steps, but when you have to do it every day, you realize that those steps are way more than just clicking on the app's icon to launch it.

Is there any chance that this option will be added to the settings?

[luncht1me]

add --disable-gpu to your shortcut or alias code="code --disable-gpu"

[amitkvmz]

go to properties / compatibility / run this program in compatibility mode for windows 7.

And everything will be working as you want.

[GazizovMarat]

@amitkvmz Thanks a lot. Also it works fine with the Windows 8 compatibility mode.

[fleps]

I hope this gets added as setting also, because every time VSCode updates, it rewrites the shortcut so I lose the --disable-gpu.
The workaround is to create a manual shortcut, which is kind of a lame workaround you know =)

[mindplay-dk]

Had to disable this to make a (window) screen recording with OBS.

I didn't find the disableHardwareAcceleration setting in User Settings?

I had to disable it by creating a custom shortcut with the --disable-gpu flag added.

[hallsbyra]

I'd also like a machine wide config of this. Running VSCode in Win10 VMWare Guest and can't get decent peformance without --disable-gpu. But the command line option is not an alternative when opening code from explorer (context menu, double clicking, etc.).

[scarolan]

I'm running VSC on a Surface Book 2, Windows 10 with WSL. The integrated terminal was super laggy and would even cause the entire program to lock up. After stumbling around and searching I discovered --disable-gpu which seems to have fixed the problem.

+1 for a way to permanently set this.

[fleps]

Guys, now that VS Code is getting new versions / updates consistently we REALLY need this option to be part of the settings.

Every time I update VS Code it overwrites my shortcut removing --disable-gpu from it, and it's getting annoying having to remember to add it each time.

We need a better solution that is permanent, even if this is a separate shortcut that you guys create each update, whatever you think is best.

Please.

[chwzr]

how to make a custom shortcut? or how to add the commandline flag in the dock in osx?
please add a user setting to disable the gpu soon!!!
its so annoying to always open the terminal before opening a document from finder...

[maccurt]

Come on there has to be a fix for this!!

[YahyaBagia]

macOS users can try the following commands in the terminal :

Goto Applications folder :
cd Applications

Open VS Code with GPU Disabled :
Visual\ Studio\ Code.app/Contents/MacOS/Electron --disable-gpu

Note : You might need to supply sudo with second command.

[fleps]

I'm LITERALLY holding VSCode updates due to this issue, as every time it updates it rewrites ANY windows shortcut, even the custom ones I create.

[luncht1me]

@fleps just make a new shortcut, you're a programmer my dude

[fleps]

@luncht1me lol what? Creating a shortcut has nothing to do with programming, neither having to re-create it every time VS code get updated.

This is about user experience.

[AbstractFlame]

Hi Guys,

I have a Thinkpad x220 with windows 7 and have the same bug, but nothing helps. Neither "--disable-gpu" and running "windows 7 compatibility mode" (on windows 7 LOL).

The bug is very strange: scrolling with the "trackpoint center button" is very-very slow or totally impossible. When I push the control button while scrolling then scrolling is totally fine, but a bit unconfortable and unusual scrolling this way for me...

I love your software so much, so I hope you'll fix this issue soon.

Best,
Sami

[deftdawg]

Ditto to @AbstractFlame , I have a Win7 Thinkpad that I can't use VSCode on my secondary displays (tried with both the lenovo USB3 dock to DP + HDMI and also with a cheap USB2VGA adapter)... Tried both --disable-gpu and Win7 Compatibility

[innerlee]

--disable-gpu do not work on my surface book 2. using the latest insider (1.25.0) now.

[scarolan]

I am also running into all sorts of performance issues with VSC running on a Surface Book 2. VSC hangs about every second or third time I run it, which is a shame because it's such a great text editor. I've discovered that starting up the editor with --disable-gpu seems to ameliorate these issues, but it's a super PITA to have to fire up VSC from the command line every single time I want to use it.

Please add a way to permanently disable GPU rendering. (Or fix the gpu rendering so it doesn't hang the entire program).

[alpraluv]

Bump.

[johnbindel]

Dell XPS 15 has this same issue due to a 4k screen. After months of just dealing with this issue by running cmd or Powershell outside of VS Code, I found the --disable-gpu flag workaround to solve the problem. I'm happy that this can be solved, but this is very clearly something that belongs in the settings of VS Code.

[johnbindel]

Okay... I've just finished investigating.

So how can we make this work without the --disable-gpu flag?

It all starts at the bootstrap of VS Code: https://github.com/Microsoft/vscode/blob/master/src/main.js#L434

With a call to app.disableHardwareAcceleration() this problem seems to be fixed (though perhaps also setting "terminal.integrated.rendererType": "dom" in addition).

So how can we make this --disable-gpu thing a viable setting that a user can enable/disable? Well if we create the setting then we have a few options for how we can address it:

1. Find environmentService.appSettingsPath and manually parse this setting on bootstrap (somewhere near https://github.com/Microsoft/vscode/blob/master/src/main.js#L434). This would occur once here and then would still need to be loaded again in ConfigurationService.

2. Create another file prestartSettings.json for settings that are needed before electron starts. This file can be saved when the regular app setting changes (in reloader.contribution.ts). Then read these settings before electron starts in the bootstrap sequence.

3. Refactor app settings loading before electron starts

   • 3a. Refactor IOC registration to before electron starts. See createServices() at https://github.com/Microsoft/vscode/blob/master/src/vs/code/electron-main/main.ts#L55

   • 3b. Load app settings and have IOC registration function take the IConfigurationService as a parameter.

4. Introduce a custom build that has hardware acceleration disabled. Not a great solution-- it would double the number of build configurations.

5. Don't fix this. Make developers work around the problem.

I'm open to feedback or other suggestions as some of these are fairly core changes. What do you think @joaomoreno, @bpasero, VS Code community?

[ebelew]

Would an environment variable be simpler than refactoring the entire configuration framework?

[johnbindel]

@ebelew It would be simpler (and I think I would be happy enough with it) but can this issue be solved with an environment variable? Please post a proposed solution.

[AbstractFlame]

@ebelew : just think about that how many people use this cool software and sum this little stresses of all users. Than you can see it is a big stress overall. You can make happier a lot of people with correct this very basic problem. (Using mouse wheel is one of the main functionality in a code editor).

[ghost]

Please add a configuration option for this. I have to always launch VS Code with --disable-gpu, but every time the app restarts due to an update, it won't remember the launch options that I used and will re-launch without --disable-gpu. Sometimes I forget this, and this is especially frustrating when I'm profiling a GPU-heavy application, because if VS Code has hardware acceleration enabled, it will skew the results significantly.

[perlun]

@johnbindel

Create another file prestartSettings.json for settings that are needed before electron starts. This file can be saved when the regular app setting changes (in reloader.contribution.ts). Then read these settings before electron starts in the bootstrap sequence.

I think this option is perhaps one of the better ones. Clearly, this relates to "startup settings" for Electron and there might potentially (in the future) be other command line options we would like/need to add to Electron's startup. So, making some kind of mechanism to handle such things gracefully would be very nice.

(For reference: https://github.com/electron/electron/issues/4380 which describes why I desperately need this flag.)

[darren-dev]

Working on a PIXI (Browser 2D engine) application completely destroys the usability of VSCode unless the ---disable-gpu flag is set. How is this still not a feature after all this time?

[bpasero]

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

• macOS: Download
• Linux: Download
• Windows: Download

[johnbindel]

Night-and-day difference for me, @bpasero! Thank you for following up on this issue. I hope Electron 3 / Chrome 66 will be a fix that works for everyone.

What timeframe might we expect to see this get to Insiders and then Mainstream release?

[bpasero]

@johnbindel still maybe 2-3 months out. if you stick to the exploration build you will get insiders (= nightly) quality but everything should work fine. We in the team have some people also using these builds daily, so we would see breakage quite quickly and resolve it.

Night-and-day difference for me

Can you elaborate what exactly is better now?

[darren-dev]

@bpasero Update from my side:

While developing for a PIXI game, my GPU usage peaks at around 96%, and on average is at 92% on a complex scene (So this would be considered an extreme case). I noticed an overall improvement in typing delay, (strangely) recompilation of webpack through the integrated console, and smoother scrolling.

The delays in the above will of course still be there due to the strain on the overall system (Though I should note there is no lag on moving the window as a whole, but there is definitely lag in moving the window sections inside VSCode [stable and your insider])

So winding down to a more manageable 70% GPU usage, the difference become less apparent

Hope this helps!

[johnbindel]

@bpasero Previously scrolling in the console would grind VS code to a halt- so bad that I would not use the embedded console. This is now snappy, just as I would hope for. Back to integrated development!

Every 1-3 hours of use the application would be very(!) sluggish to scrolling and clicking. This could be resolved by minimizing or full-screen toggling the app and it would immediately be faster. I'm not seeing this behavior yet, and I'm optimistic that it is resolved.

[bpasero]

Previously scrolling in the console would grind VS code to a halt- so bad that I would not use the embedded console. This is now snappy, just as I would hope for. Back to integrated development!

@Tyriar fyi on that, I thought we would fallback to DOM rendering (not sure that applies here).

Every 1-3 hours of use the application would be very(!) sluggish to scrolling and clicking. This could be resolved by minimizing or full-screen toggling the app and it would immediately be faster. I'm not seeing this behavior yet, and I'm optimistic that it is resolved.

Interesting, not sure I heard of that before. What OS are you on?

@darren-dev thanks for sharing

[Tyriar]

fyi on that, I thought we would fallback to DOM rendering (not sure that applies here).

There was a regression in 1.26 which is fixed in 1.27 that would draw everything in the terminal when only a subset of the lines were required so this was mixed in with some of the GPU issues. Everything should be back to normal now and the fallback notification occurs if frames are slow.

[kittle31]

This worked for me -- maybe it can help others

On my windows PC, i have an nvidia card, so I added a profile for vs code in the control panel, and disabled all the anti-alias settings. All the text is now clear and readable.

[leecommamichael]

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

* macOS: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/VSCode-darwin-exploration.zip)

* Linux: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/code-exploration_1.28.0-1536650436_amd64.deb)

* Windows: [Download](https://az764295.vo.msecnd.net/exploration/86ff36a1cca2c5763c9c57bda2ec8d3443538c89/VSCodeUserSetup-x64-1.28.0-exploration.exe)

This fixed my lag experienced in 43137, there is a general issue with macOS' WindowServer process eating CPU, but not in this build. Thank you!!! Scrolling is finally smooth and responsive again!

[givethemheller]

Why don't we allow this just for the sake of battery performance?

I run an older MBP - it's been upgraded to keep up with modern hardware, only efficiency being battery life (it's been replaced recently). Why should I kill 45 min to an hour of operation for GPU acceleration?

[thesleort]

@givethemheller usually you want GPU acceleration, since the GPU is more efficient than your CPU at certain tasks, and therefore will give you more battery life than disabling the GPU. Problem is that sometimes the GPU is not told properly what to do and how to do it, which can result in graphical artefacts. In these cases it is nice to be able to disable the GPU acceleration.

[givethemheller]

Well, I guess to that end - why would I want to be using the discrete GPU instead of the chip-set GPU? I would expect there to be performance increase on the discrete GPU with a hit to battery life vs the on board chip set gpu.

[aurelienrb]

I use VSCode from virtual machines with Virtual Box and I can confirm that it still runs very slowly if not started with the --disable-gpu option.
Having a dedicated option would make things simpler than manually creating and patching Gnome launchers.

[Craig-Macomber]

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:

Download:

• macOS: Download
• Linux: Download
• Windows: Download

On my Linux setup I got all kinds of graphical issues and bad performance (mostly disappearing rectangles of UI including the terminal, text editors, bottom bar, but also other parts of the UI) when I moved to an AMD graphics card from my Nvidia one (I changes a few things at the same time, but I suspect it was the GPU and driver swap). --disable-gpu does not fix my problems, however your exploration build fixes it: its fast and renders correctly :) (and I have no other work around, I was going to have to get a different editor!)

[Tyriar]

@Craig-Macomber I guess Chrome 58 was just really buggy on your hardware. FYI if you see that in the terminal you should be able to work around it by switching the renderer to use the DOM:

"terminal.integrated.rendererType": "dom"

[shalkam]

So, the --disable-gpu flag doesn't work at all for me, I guess it's no longer supported in electron.js
I had to go and add app.disableHardwareAcceleration(); directly into /usr/share/code/resources/app/out/main.js

like this app.on("will-finish-launching",function(){app.disableHardwareAcceleration();
inside the callback for will-finish-launching event

[rpavlik]

People that face UI issues and need to run with --disable-gpu, I am releasing VSCode exploration builds with Electron 3.0.x and Chrome 66. If that builds fixes the issues for you, I would love to get more selfhosting and feedback. I keep these builds updated manually every 2-3 days with latest from master:
Download:

• macOS: Download
• Linux: Download
• Windows: Download

On my Linux setup I got all kinds of graphical issues and bad performance (mostly disappearing rectangles of UI including the terminal, text editors, bottom bar, but also other parts of the UI) when I moved to an AMD graphics card from my Nvidia one (I changes a few things at the same time, but I suspect it was the GPU and driver swap). --disable-gpu does not fix my problems, however your exploration build fixes it: its fast and renders correctly :) (and I have no other work around, I was going to have to get a different editor!)

I had the same issue (chunks disappearing on an AMD RX580 on Linux), which I had blamed on a bad GPU - but now the GPU has been replaced and works on Windows, and still got chunks. This test build (exploration 1.28.0) seems to work well so far, but am now updating and am transfered to Insider - will update if it changes.

[perlun]

@shalkam Something like this, or do you mean straight inside the will-finish-launching handler?

    app.on("will-finish-launching", function () {
        app.on("open-url", t)
        app.on("will-finish-launching",function() { app.disableHardwareAcceleration(); }) // <-- added line
    }), global.getOpenUrls = function () {
        return app.removeListener("open-url", t), r
    }

---

FWIW, the problem has gotten worse for me. I put my (Linux) desktop to sleep every night when heading home from work; every morning now, VSCode is unresponsive and can't even be closed with the UI controls. I have to killall code to restart it. Highly annoying.

Here is the exact version I'm running:

$ code --version
1.30.2
61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
x64

nVidia GPU; I recently upgraded my Debian to latest packages (I am running unstable), so this might affect the problem also. Here is the package version:

$ dpkg -l nvidia-driver
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  nvidia-driver  390.87-2     amd64        NVIDIA metapackage

[shalkam]

@perlun you're adding will-finish-launching twice, which is wrong
You just need to add this part app.disableHardwareAcceleration(); only after the curly bracket

app.on("will-finish-launching",function(){app.disableHardwareAcceleration()

[perlun]

@shalkam Thanks! Yes, the way I wrote it looked kind of insane. =)

For reference, here it what it looks like with the added change (file de-minimized by vscode's built-in formatter):

function registerListeners() {
    const e = [];
    global.macOpenFiles = e, app.on("open-file", function (r, t) {
        e.push(t)
    });
    const r = [],
        t = function (e, t) {
            e.preventDefault(), r.push(t)
        };
    app.on("will-finish-launching", function () {
        app.disableHardwareAcceleration(); // <-- added line
        app.on("open-url", t);
    }), global.getOpenUrls = function () {
        return app.removeListener("open-url", t), r
    }
}

[JavierFuentes]

@shalkam,
I can't find /usr/share/code/resources/app/out/main.js file in my OS X machine...

Do you know where is it in OS X?

[dschuessler]

Right click on Visual Studio Code in the Applications folder and click on „Show package contents“ (It might be a bit different. I’m not on an English OS X right now.). Now navigate to /Contents/Resources/app/out/main.js.

Am 03.03.2019 um 10:38 schrieb Javier Fuentes [e-mail]:

@shalkman,
I can't find /usr/share/code/resources/app/out/main.js file in my OS X machine...

Do you know where is it in OS X?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/Microsoft/vscode/issues/15211#issuecomment-469005386, or mute the thread https://github.com/notifications/unsubscribe-auth/AFgc0dZwY6bBsKXJKqCumt3m6dxH13TFks5vS5gwgaJpZM4Ks8ad.

[JavierFuentes]

@dschuessler,
thank you so much... It works like a charm!

I hope we don't need this kind of hacking and we'll can configure this in VSCode settings in near future or MS fix this in the source code.

[harleyguru]

@Craig-Macomber I guess Chrome 58 was just really buggy on your hardware. FYI if you see that in the terminal you should be able to work around it by switching the renderer to use the DOM:

"terminal.integrated.rendererType": "dom"

This is the solution until electron will fix the issue?

[AlekEagle]

Had to disable this to make a (window) screen recording with OBS.

I didn't find the disableHardwareAcceleration setting in User Settings?

I had to disable it by creating a custom shortcut with the --disable-gpu flag added.

disableHardwareAcceleration is a electron function. Not a user setting.

[JavierFuentes]

After last automatic update to 1.3.32 version, seems code --disable-gpu has stopped solving the problem in my Hackingtosh PC.

Fortunately, hacking .app with @shalkam 's solution continues solving my problem.

[davidpcaldwell]

For what it's worth, my experience on an OS X VM (with buggy graphics driver) was that passing the command-line switch worked, but exiting the application (even using Command-Q) was insufficient to reset the behavior -- after rebooting, things started to work. Something may be hanging around in the background.

[TheSeven]

So the Electron black window issue is known since more than 3 years and still not fixed, and more than 2 years ago, this issue was opened to ask for any sane workaround for it.

I still can't find a way to make VSCode run without GPU acceleration reliably. Shortcuts are being overwritten by updates and only work for launching VSCode through that specific shortcut anyway, and not when e.g. launching it from the context menu of a file.

Having a config option for this seems like the way to go, but even an environment variable or any other means of allowing to specify this setting in a way, that 1. persists across updates and 2. gets applied regardless how VSCode is launched, would be tremendously helpful.
Given that this works around an Electron issue, it would be even more useful if it would be added to Electron so that it works around this issue for all Electron-based apps, but it doesn't look like this is going to happen anytime soon.

Currently, this issue is making VSCode unusable on my laptop.
(For reference: On that hardware, Slack shows the same symptoms, but when disabling GPU acceleration within Slack, it works just fine, and the setting sticks across updates. Current Chrome doesn't have any issues without any workarounds.)

[jcayzac]

@givethemheller usually you want GPU acceleration, since the GPU is more efficient than your CPU at certain tasks, and therefore will give you more battery life than disabling the GPU. Problem is that sometimes the GPU is not told properly what to do and how to do it, which can result in graphical artefacts. In these cases it is nice to be able to disable the GPU acceleration.

For many laptop users, "efficiency" is defined as in "hours of operation on battery power", not rendering speed of display buffers. For people like us lot with both a very limited integrated intel GPU and an additional "high performance" GPU, anything requiring the latter effectively cuts battery life by half. Are you saying that this is not an important usability problem that should be fixed?

[perlun]

Interestingly enough, this problem might have disappeared for me: I suspended the machine yesterday, and resumed it today, but my VSCode instance survived! :astonished:

The version I use is 1.32.2-1552488294, Debian GNU/Linux with nvidia-driver version 390.87-2.

The GPU process seems to be running with these settings:

$ ps -fe | grep code/code | grep gpu
per      32286 32250  0 apr11 tty7     00:01:16 /usr/share/code/code --type=gpu-process --no-sandbox --gpu-preferences=KAAAAAAAAACAAACAAQAAAAAAAAAAAGAAEAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAA --service-request-channel-token=BBCE5<...removed...>

[bgarrant]

We need this badly. Having to start VS Code with command line code --disable-gpu every time is a pain. There is no way to set this in the config somewhere?

[justcfx2u]

@bgarrant

Modify VSCode Shortcut

This seems to work for me on Windows.

[bgarrant]

I am on a Mac and do not see a way to make the shortcut from the dock do this. I can use the flag with the terminal to open, but that is not a good user flow. We need a setting for this.

[justcfx2u]

@bgarrant

I fully agree that it should be easier.

Here's what I did on my Mac

Editing /Applications/Visual Studio Code.app/Contents/Resources/app/bin/code (I used Terminal to cd down into Visual Studio Code.app and vi to edit the file) and adding --disable-gpu on the line

ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"

so that it becomes

ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --disable-gpu "$@"

seems to work for me when launching from the Dock.

This might need to be re-edited every time you upgrade VS Code, but it's better than trying to launch it through the Terminal every time you want to open the program.

[bgarrant]

I will try that. Thanks.

[miketemby]

3 years.... :(

My 2010 MBP has a failing discrete GPU so I've had to turn off GPU acceleration on all my apps for now. VS Code is the only one that doesn't have an option to do this in settings.
I'm no app developer but I would have thought this would be fairly simple to add as a setting for users to control. It's frustrating to come here and see that it's been requested for 3 years and not addressed.

On my MBP I had to use the following command to launch from terminal:
Visual\ Studio\ Code.app/Contents/MacOS/Electron --disable-gpu
..from within applications folder.

@justcfx2u I tried the edit you suggested but it didn't work for me. It had no effect.

[bgarrant]

@miketemby I feel the same. When you do it the way it has to be done again
on every update. VS Code needs a setting for this.

[bgarrant]

Sublime and even Atom has a setting for this. C’mon team!

[bgarrant]

We need this feature very badly. Opening Visual Studio Code by the command line several times per day sucks.

[mchenx]

for some macbook pros that have AMD GPU issue need this feature, otherwise the laptop would reboot every time tries to launch vs code.

[mlindner]

Microsoft seems to require high performance video cards for a lot of their programs now. Now Microsoft Teams also requires the --disable-gpu option. Microsoft can't seem to tell the difference between using graphics acceleration and forcing the computer to switch to a high performance video card.

[mlindner]

@bpasero please remove the feature-request setting as this is actually a bug, not a feature request. It causes performance and usability problems on a vast number of computers.

[thatandyrose]

Hi VSCode team, any reason why you don't want to address this issue? Seems like a simple fix that could save quite a lot of pain for a lot of people?

I'd love to hear the argument against doing it?

thanks so much!

[evan-zubov]

Oh my god, I was ready to dump my 2012 macbook because of how slow it was with chrome and vscode, but after disabling acceleration in both it is so much faster now! Come on, guys, please, add the switch!

[bgarrant]

what do we need to do to get this added as a configuration option in VS Code? You already have the function. Can you all please just add an option to change it "within" VS Code?

[bpasero]

Current idea (and pushed): have a new %user.home%/.vscode/argv.json file that allows to configure static arguments.

Contents:

Getting There:

We will probably add more values as default there. Possibly also the language configuration which currently resides in a locale.json file.

Feedback welcome.

[miketemby]

@bpasero Excellent that this is getting addressed!!!

feedback:
Is there potential to just add this as an option within Preferences > Settings so users can just switch on or off GPU acceleration without needing to modify a JSON file?
Might be easier for users that are not so technically skilled.

[bpasero]

@miketemby since extensions can change settings programmatically and this can have quite an impact, it feels wrong to have it in a place that is not 100% under the control of the user.

[miketemby]

@miketemby since extensions can change settings programmatically and this can have quite an impact, it feels wrong to have it in a place that is not 100% under the control of the user.

Fair enough. I'm happy either way. cheers.

[usernamehw]

@bpasero Why is it so limiting? I thought it would be possible to add any arguments like --enable-proposed-api or --disable-smooth-scrolling but they do not work.

[bpasero]

@usernamehw first of all, not all Chrome command line switches can be set that late. Many of the GPU related switches will only work if you configure them on the command line so that Chrome gets them very early. Setting them within our code is often too late.

I also think we should be careful with what we want to support from this file. I am open to adding more things to the file on a case by case basis if it makes sense and a lot of people would benefit from it.

[mlindner]

Is there a similar issue created for Microsoft Teams? Teams has the same issue. This seems like a base Microsoft library issue rather than an issue specific to VSCode.

[aaomidi]

What if I want to disable it with a command line switch? Is that possible? For example if I'm doing some testing in CI.

[bpasero]

@aaomidi what exactly do you want to disable?