Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd a setting to disable gpu acceleration #15211
Comments
This comment has been minimized.
This comment has been minimized.
Forgot VS Code version (sorry). -fixed- |
This comment has been minimized.
This comment has been minimized.
@SpaceShot are you saying that you see the first window with GPU disabled but subsequent windows are not? |
aeschli
assigned
bpasero
Nov 9, 2016
bpasero
added
the
needs more info
label
Nov 9, 2016
bpasero
added this to the Backlog milestone
Nov 9, 2016
This comment has been minimized.
This comment has been minimized.
There is |
This comment has been minimized.
This comment has been minimized.
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 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 I simply was adding more information that I tried a few things, such as opening with |
bpasero
changed the title
Disable gpu setting in user settings
Add a setting to disable gpu acceleration
Nov 11, 2016
bpasero
added
feature-request
workbench
labels
Nov 11, 2016
bpasero
removed this from the Backlog milestone
Nov 11, 2016
bpasero
removed their assignment
Nov 11, 2016
bpasero
removed
the
needs more info
label
Nov 11, 2016
This comment has been minimized.
This comment has been minimized.
billscheidel
commented
Dec 10, 2016
•
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? |
CoenraadS
referenced this issue
Apr 11, 2017
Closed
Windows: Scrolling is not smooth but lags #13612
This comment has been minimized.
This comment has been minimized.
faustotnc
commented
Sep 19, 2017
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 Is there any chance that this option will be added to the settings? |
This comment has been minimized.
This comment has been minimized.
luncht1me
commented
Sep 30, 2017
add |
donmckenna
referenced this issue
Oct 26, 2017
Closed
Terminal Window doesn't always display properly #35915
bpasero
added
workbench-electron
and removed
workbench
labels
Nov 16, 2017
bpasero
referenced this issue
Nov 17, 2017
Closed
Add an configure options let us disable GPU hard ware accelerate #23324
This comment has been minimized.
This comment has been minimized.
amitkvmz
commented
Dec 12, 2017
go to properties / compatibility / run this program in compatibility mode for windows 7. And everything will be working as you want. |
This comment has been minimized.
This comment has been minimized.
GazizovMarat
commented
Jan 4, 2018
@amitkvmz Thanks a lot. Also it works fine with the Windows 8 compatibility mode. |
This comment has been minimized.
This comment has been minimized.
fleps
commented
Mar 21, 2018
I hope this gets added as setting also, because every time VSCode updates, it rewrites the shortcut so I lose the --disable-gpu. |
This comment has been minimized.
This comment has been minimized.
mindplay-dk
commented
Mar 22, 2018
Had to disable this to make a (window) screen recording with OBS. I didn't find the I had to disable it by creating a custom shortcut with the |
This comment has been minimized.
This comment has been minimized.
koffmoff
commented
Apr 17, 2018
I'd also like a machine wide config of this. Running VSCode in Win10 VMWare Guest and can't get decent peformance without |
This comment has been minimized.
This comment has been minimized.
scarolan
commented
Apr 19, 2018
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. |
This comment has been minimized.
This comment has been minimized.
fleps
commented
May 9, 2018
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. |
This comment has been minimized.
This comment has been minimized.
chwzr
commented
May 9, 2018
•
how to make a custom shortcut? or how to add the commandline flag in the dock in osx? |
This comment has been minimized.
This comment has been minimized.
maccurt
commented
Jun 9, 2018
Come on there has to be a fix for this!! |
This comment has been minimized.
This comment has been minimized.
johnbindel
commented
Jul 29, 2018
•
Okay... I've just finished investigating. So how can we make this work without the It all starts at the bootstrap of VS Code: https://github.com/Microsoft/vscode/blob/master/src/main.js#L434 With a call to So how can we make this
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? |
This comment has been minimized.
This comment has been minimized.
ebelew
commented
Aug 22, 2018
Would an environment variable be simpler than refactoring the entire configuration framework? |
This comment has been minimized.
This comment has been minimized.
johnbindel
commented
Aug 22, 2018
@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. |
This comment has been minimized.
This comment has been minimized.
AbstractFlame
commented
Aug 23, 2018
@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). |
This comment has been minimized.
This comment has been minimized.
Please add a configuration option for this. I have to always launch VS Code with |
This comment has been minimized.
This comment has been minimized.
perlun
commented
Sep 3, 2018
•
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.) |
This comment has been minimized.
This comment has been minimized.
darren-dev
commented
Sep 13, 2018
Working on a PIXI (Browser 2D engine) application completely destroys the usability of VSCode unless the - |
This comment has been minimized.
This comment has been minimized.
People that face UI issues and need to run with Download: |
This comment has been minimized.
This comment has been minimized.
johnbindel
commented
Sep 13, 2018
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? |
This comment has been minimized.
This comment has been minimized.
@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.
Can you elaborate what exactly is better now? |
This comment has been minimized.
This comment has been minimized.
darren-dev
commented
Sep 13, 2018
•
@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! |
This comment has been minimized.
This comment has been minimized.
johnbindel
commented
Sep 13, 2018
@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. |
This comment has been minimized.
This comment has been minimized.
@Tyriar fyi on that, I thought we would fallback to DOM rendering (not sure that applies here).
Interesting, not sure I heard of that before. What OS are you on? @darren-dev thanks for sharing |
This comment has been minimized.
This comment has been minimized.
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. |
bpasero
referenced this issue
Sep 14, 2018
Closed
Preserve custom command line in /usr/share/applications/code.desktop #58635
This comment has been minimized.
This comment has been minimized.
kittle31
commented
Sep 14, 2018
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. |
This comment has been minimized.
This comment has been minimized.
leecommamichael
commented
Sep 24, 2018
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! |
leecommamichael
referenced this issue
Sep 24, 2018
Open
Input lag on High Sierra and scaled display resolution mode #43137
bliden
referenced this issue
Oct 13, 2018
Open
Scrolling with middle mouse + trackpoint is extremely difficult #60841
This comment has been minimized.
This comment has been minimized.
givethemheller
commented
Oct 14, 2018
•
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? |
This comment has been minimized.
This comment has been minimized.
thesleort
commented
Oct 14, 2018
@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. |
This comment has been minimized.
This comment has been minimized.
givethemheller
commented
Oct 15, 2018
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. |
This comment has been minimized.
This comment has been minimized.
aurelienrb
commented
Oct 17, 2018
I use VSCode from virtual machines with Virtual Box and I can confirm that it still runs very slowly if not started with the |
This comment has been minimized.
This comment has been minimized.
Craig-Macomber
commented
Dec 12, 2018
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!) |
This comment has been minimized.
This comment has been minimized.
@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:
|
This comment has been minimized.
This comment has been minimized.
shalkam
commented
Dec 14, 2018
•
So, the like this |
This comment has been minimized.
This comment has been minimized.
rpavlik
commented
Dec 17, 2018
•
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. |
This comment has been minimized.
This comment has been minimized.
perlun
commented
Jan 29, 2019
@shalkam Something like this, or do you mean straight inside the 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 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 $ 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 |
This comment has been minimized.
This comment has been minimized.
shalkam
commented
Feb 13, 2019
@perlun you're adding
|
This comment has been minimized.
This comment has been minimized.
perlun
commented
Feb 17, 2019
•
@shalkam Thanks! Yes, the way I wrote it looked kind of insane. =) |
SpaceShot commentedNov 8, 2016
•
edited
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:
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