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.

[koffmoff]

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

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

[aleksijuvani]

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: electron/electron#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. =)