Vscode: Terminal is unusably slow due to GPU blacklisting

[grigorig]

• VSCode Version: 1.26.0
• OS Version: Fedora 28

Steps to Reproduce:

1. Start VSCode
2. Try to use the integrated terminal - it's very slow

My system uses an AMD RX 480 GPU with Mesa 18.0.5 as the OpenGL driver. For some reason, Electron puts me onto the GPU blacklist, which results in bad performance. It's especially noticeable with the integrated terminal, which is unusably slow.

Starting VSCode with the --ignore-gpu-blacklist flag fixes the performance problems, with no noticeable issues.

It is unclear if my system/GPU was on the blacklist on previous VSCode versions as well, but they did not have the severe performance issues with the terminal.

So this might be two issues, I'm not sure: First, VSCode's terminal is extremely slow without GPU acceleration in 1.26.0, and apparently this wasn't a problem before. Second, VSCode/Electron seems to blacklist various GPU/driver combinations for no specific reason. I'm using an up to date driver with a contemporary GPU and acceleration should work just fine.

[grigorig]

The aggressive GPU blacklist might actually be a problem with Electron 2.x:

https://github.com/electron/electron/issues/12042
https://github.com/electron/electron/issues/11051

Note: to give you some idea, "very slow" means it might take close to a second for a redraw of the terminal! It should not be that slow even with software rendering.

[MastroLindus]

I have the same issue on Linux Mint 18.3. ignore-gpu-blacklist fixes the issue.
I also have a related issue in 1.26.0 that I never had in 1.25.0 or before: when editing a TSX file, sometimes changing a tag causes a big jsx block to be invalid and normally the lines would be highlighted in red.
Sometimes when this happens now the whole visual code rendering freaks out and becomes unusable, e.g. most of the screen becomes black, you get weird characters on screen, and trying to move the mouse and interact with code has weird outcomes (I think the functionality keeps working, like pressing a button, but because the rendering fails you don't get a proper UI feedback of it).
Since I use the --ignore-gpu-blacklist I didn't see the problem again.

[grigorig]

Is it possible to permanently set --ignore-gpu-blacklist in the preferences? That might be an acceptable workaround, short-term.

[stgogm]

I've also tried setting "terminal.integrated.rendererType" to "dom" and in fact, it is more responsive but it has padding issues.

[marcelofrau]

On the 1.25.0 even using canvas mode the performance on terminal is absurdly faster. On the 1.26.0 even with --ignore-gpu-blacklist the terminal suffers from slowdowns here on my enviroment. I am rolling back to 1.25.0 temporarily. :(

Changing to dom the rendererType solves the problem but the terminal here is getting a lot of padding issues.

I am currently working inside a virtualbox machine with no 3d acceleration (due to linux incompatibilities) and the performance is heavily noticed here.

Please fix this issue, if you need some help or some tests on my enviroment please let me know and I will be glad to contribute.

Thanks.

[Tyriar]

The GPU blacklisting problem does go away with Electron 3 (https://github.com/Microsoft/vscode/issues/52629, for the most part at least). The dom renderer was added such that we have a reasonable experience when Chromium wants to disable the GPU like this (as we don't know why it wants to disable).

Something to note though is that there was also a pretty bad terminal perf regression in 1.26 which is fixed, I expect the experience in Insiders (tomorrow's build) to be much better for both canvas and dom renderers. https://github.com/Microsoft/vscode/issues/56628

Let's track the slow GPU issue due to Electron in this issue.

[fractos]

Hitting this issue on a Lenovo T470s (high dpi main display - 2560x1440) since last update to 1.26.* and have been getting notification about terminal renderer being slow. Switching to dom renderer type didn't help. I generally run with --disable-gpu since I get scroll issues on touchpad and I've tried with and without that. However, starting Code with --ignore-gpu-blacklist has completely alleviated the terminal being slow.

[davidstl]

Hi guys, I am not on Insider, but 1.26.1. And even with --ignore-gpu-blacklist it is still slow and unsusable if I make the terminal fullscreen.

Specs: i7 PC with GForce 1050.

[Tyriar]

@davidstl could you check if it improved on Insiders to see if https://github.com/Microsoft/vscode/issues/56628 was your problem?

[marcelofrau]

@Tyriar I am still having slowdown issues with the latest insiders version.. :(

[Tyriar]

@marcelofrau you mentioned this:

Changing to dom the rendererType solves the problem but the terminal here is getting a lot of padding issues.

The padding issues should be fixed in 1.26, I think your unfortunately on an environment that Chromium treats a little funny, which was the reason for the dom renderType being introduced. I'd stick with DOM for now and try switch again when our Electron 3 build comes out https://github.com/Microsoft/vscode/issues/52629

[clor09]

got this problem too with ver 1.27.2 , and ignore gpu blacklist works~ and just for a note: this also fix the hyper termnial~ it should be tracked~~

[yoisel]

I use vscode on xubuntu 18.04 over remote desktop (xrdp). In my case it is also unusable.

[CkTD]

the flag works for me with version 1.29.1 on fedora 29

[Tyriar]

Since we just merged in Electron 3 to Insiders (v1.31) I'm going to call this closed. If you do still see slowness issues the first thing you should do is turn on the DOM renderer by adding this setting (you should be prompted automatically to switch if your terminal is slow):

"terminal.integrated.rendererType": "dom"

The DOM renderer's performance has also improved a lot in Insiders due to https://github.com/xtermjs/xterm.js/pull/1792, it's not meant to be faster than canvas but it should be reasonable. If you see any bad performance issues with the DOM renderer please file an issue.

I'll lock this to prevent this information from being buried.