Large portions of the window not repainting on high DPI/resolution displays

[BytewaveMLP]

Issue Type: Bug

When VS Code sits open for a while, say in the background or after an unmeasured time of just sitting around, large portions of the window appear to not repaint. This also occurs with more "complicated" views, such as the terminal or git diff views, upon scrolling. This causes an insane amount of flickering, and in git diff views it's almost impossible to use as large portions of the screen don't repaint upon scrolling.

This does not occur in other Electron apps, such as Discord or GPMDP, nor does it appear in Chromium or Chrome (not that I suppose that matters).

I know this is a bit of a duplicate of old issues, as I've seen issues like #12473 before, but all of those have been marked as resolved. I don't know if it's my system specifically or what, but none of the fixes in any of these issues seem to work; not even --disable-gpu, --force-gpu-rasterization, window.zoomLevel: 0, or any of the other tricks have had any effect.

I don't see it mentioned in the system info, so I suppose I should also note that I'm running on an AMD RX 480 with mesa and the AMDGPU open source drivers, on KDE X11.

Screenshots

(Both of these are more related to the git diff issue, but I don't have a good way to record nor reproduce the time-based flickering issue yet.)

Launched with --disable-extensions. Notice how a lot of the code is missing, and the terminal has a very large section of gray.

Yet another screenshot, this one with more pronounced differences. Interestingly, scrolling around in the git diff view seems to partially fix the terminal, and vice versa, even though the panel being scrolled becomes more broken.

Steps to reproduce

1. Launch VS Code (even with --disable-gpu or --force-gpu-rasterization)
2. Open a git diff view, or let the editor sit for a while
3. Observe obnoxious rectangles

VS Code version: Code 1.21.0 (9a199d7, 2018-03-07T11:01:43.521Z)
OS version: Linux x64 4.15.7-1-zen

System Info

Item	Value
CPUs	AMD FX(tm)-8350 Eight-Core Processor (8 x 3734)
Load (avg)	1, 2, 1
Memory (System)	15.61GB (5.59GB free)
Process Argv	/opt/visual-studio-code/code
Screen Reader	no
VM	0%

Extensions (51)

Extension	Author (truncated)	Version
language-x86-64-assembly	13x	2.2.11
vscode-markdownlint	Dav	0.13.0
EditorConfig	Edi	0.12.1
vsc-material-theme	Equ	1.5.1
much-assembly-required-language-support	PJB	0.1.5
vscode-docker	Pet	0.0.25
code-settings-sync	Sha	2.9.0
project-manager	ale	0.24.1
vscode-twig-pack	baj	1.0.0
love	bsc	0.3.6
npm-intellisense	chr	1.3.0
path-intellisense	chr	1.4.2
gitignore	cod	0.5.0
vscode-eslint	dba	1.4.7
git-extension-pack	don	0.1.3
githistory	don	0.4.0
gitlens	eam	8.1.0
tslint	eg2	1.0.28
vscode-npm-script	eg2	0.3.3
prettier-vscode	esb	1.2.2
php-debug	fel	1.12.1
php-intellisense	fel	2.2.9
auto-close-tag	for	0.5.6
code-runner	for	0.9.1
discord-vscode	icr	2.2.1
search-node-modules	jas	1.3.0
csharpextensions	jch	1.3.0
docthis	joe	0.6.0
docomment	k--	0.0.17
Go	luk	0.6.77
MagicPython	mag	1.0.12
license-injector	mar	0.0.2
dotenv	mik	1.0.1
prettify-json	moh	0.0.3
vscode-apache	mrm	1.1.1
python	ms-	2018.2.1
cpptools	ms-	0.15.0
csharp	ms-	1.14.0
PowerShell	ms-	1.6.0
debugger-for-chrome	msj	4.2.0
php-docblocker	nei	1.3.3
proto	pet	0.0.2
livescript	pse	0.1.1
sass-indented	rob	1.4.8
code-spell-checker	str	1.6.5
much-assembly-required-upload-on-save	tom	0.0.6
gitblame	wad	2.2.0
nodejs-extension-pack	wad	0.1.9
vscode-import-cost	wix	2.6.2
JavaScriptSnippets	xab	1.5.0
vscode-open-in-github	ziy	1.3.1

Reproduces without extensions

[bpasero]

@BytewaveMLP does it reproduce when you run with code --disable-gpu?

[BytewaveMLP]

@bpasero Yes. Both --disable-gpu and --force-gpu-rasterization had no effect. Extensions were disabled while testing.

[BytewaveMLP]

I feel like this has something to do with higher DPI displays. I've noticed that running Code in a smaller window seems to lessen if not eliminate the effect (but it also makes it much less usable).

For reference, this is a 4k display with 1.7 DPI scaling in KDE. But, again, other Electron applications running at the same resolution are unaffected (Discord used to be, but that was months ago; perhaps it's some sort of regression?).

My apologies for not mentioning this earlier. It hadn't really crossed my mind.

[danloiterton]

I have the same issue, running ubuntu 16.04 with a 4k monitor with an AMD graphics card (AMD OLAND (DRM 2.43.0 / 4.4.0-116-generic, LLVM 5.0.0)).

It seems to have worsened since the terminal splitting feature (which is so awesome to use on my windows laptop, but unusable on my ubuntu setup). The git diff spilt view has been causing flickering and blank rectangles for some time but I got by without using it. Now, however, the flickering is happening even when there's no screen splitting enabled.

I've also tried running code with --disable-gpu and --force-gpu-rasterization. This seems to improve the git split screen a little but certainly doesn't fix the problem, and the terminal splitting remains unusable.

Similar to @BytewaveMLP, if I reduce the window size, the problem is alleviated somewhat, but that does defeat the purpose of my shiny 4k monitor!

notice big white, grey and dark grey rectangles over the side panel and terminal windows in the example above. But it happens all over the screen, usually triggered by scrolling. Often there's flickering but it's when they don't go away and the code is obscured, that the app becomes unusable

[mix3d]

I've experienced the issue on Windows 10, laptop has a native WQHD 1440p screen, set to 150% scaling, but mostly only use a larger monitor at 100% scaling. I also get strange painting issues with terminals, and text sometimes disappears altogether until I type some commands, or the position of the current active line gets moved INTO the existing displayed console output. This was even before the split console feature.

[guioconnor]

I am running into a similar problem. I saw there are a few tickets open on similar issues, notably I followed #25934 more closely.

In my case, the problem started today, without any update, change of configurations or recent addition of extensions.

I'm running version 1.21.1 on a MacBook with 15in Retina Display (2880 x 1800). It has worked flawlessly for over a year.

What did notice is that people reporting the problem happening with 3-way screen split. Today I started using the terminal (not the editor) in a 3-way split and since then, it's been almost impossible to work around the issue.

[Tyriar]

This might workaround the problem:

code --ignore-gpu-blacklist

[mix3d]

@Tyriar how do you set code to always launch with a command?

[Tyriar]

@mix3d did it work? On Windows I think you could create a shortcut and modify it, or launch from a batch script (note it's only the first window that needs to be launched like this).

[BytewaveMLP]

Yup, it seems like --ignore-gpu-blacklist fixes it @Tyriar; however, it's annoying to have to edit all my .desktop files to support this. Fortunately, KDE makes that easy, but it's kinda difficult to set $EDITOR with flags (Code doesn't seem to like the filename being passed after command line arguments, but perhaps that's another bug to report).

I suppose a simple bash script could be used to work around these limitations, though. Something as simple as:

#/bin/bash

code "$@" --ignore-gpu-blacklist

could make a simple enough workaround.

[mix3d]

Sounds like a good opportunity to open that value as an editor config? Or is that too far into the app loading process?

[BytewaveMLP]

It could at least be a prelaunch thing. On Arch, the Google Chrome package "binary" actually Chrome from a shell script that reads a file ~/.config/chrome-flags.conf and uses its contents as command line arguments to pass to the actual Chrome instance. Something like that could be used here.

[Tyriar]

@BytewaveMLP great, we have a root cause! This is happening because Chromium maintains a list of GPUs to disable as they have issues, unfortunately in VS Code this manifests itself as corrupted textures inside the canvas for some reason.

I'm curious if the same thing happens when you run Google Chrome?

Sounds like a good opportunity to open that value as an editor config? Or is that too far into the app loading process?

@mix3d I think it's too far, we don't touch the settings file until the Electron main process is launched.

[BytewaveMLP]

@Tyriar It's hard to say. Chrome doesn't have any flickering issues when the ignore-gpu-blacklist flag is disabled, but it does seem considerably less performant, and changing views (e.g. switching tabs) does seem to cause a sort of "wiping" effect much like VS Code was exhibiting. Discord, another Electron app, used to have a similar problem to the one noted in this issue, but it would only appear at certain startups and could be fixed after a client or system restart; it was never reliable reproducible, and was fixed a while ago )likely ignoring the blacklist themselves). GPMDP, however, does have a slight flickering and poor performance problem, which does seem related.

[Tyriar]

@BytewaveMLP oh it should only show up when you're using a canvas though. To test this out you could run the xterm.js demo inside Chrome (which is what the terminal is built on) as that's a canvas that's doing a lot of painting. Try tweaking the rows/cols in the textbox below and running some commands. https://github.com/xtermjs/xterm.js#linux-or-macos

[BytewaveMLP]

Er... whoops. I guess I missed the canvas part initially. Sorry about that.

However, even with the GPU blacklist enabled and something that should cause a lot of repainting (hd /dev/urandom), I'm unable to get any flickering out of Chrome, and only some poor performance, even with an exceptionally large terminal size (500x100, anyone?).

[danloiterton]

@Tyriar I can also confirm that code --ignore-gpu-blacklist fixes this issue in vscode.

Also, chrome has been doing some similar flickering for me since I upgraded my monitors and graphics card. Not all the time but if I use some graphically intense web apps - eg. today I was building a diagram with gliffy. As the diagram became more complex, the flickering started and gradually intensified

I ran google-chrome --ignore-gpu-blacklist and this also fixed the issue!

[BytewaveMLP]

@danloiterton Don't forget that Chrome has chrome://flags which should let you set the --ignore-gpu-blacklist flag without having to pass it on the command line. Code doesn't have a similar interface, unfortunately, but at least you don't have to make a shell script for everything. :P

[jeremyfa]

Same issue here, started to have it after updating vscode last week I think. I have it on a Macbook Pro Retina 15 inches, but it doesn't occur on my secondary screen which is default DPI.

[mix3d]

what's the impact if we turn it on for all builds as part of the regular release?

…

On Thu, Mar 29, 2018, 12:12 PM Jérémy Faivre ***@***.***> wrote: Same issue here, started to have it after updating vscode last week I think. I have it on a Macbook Pro Retina 15 inches, but it doesn't occur on my secondary screen which is default DPI. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45492 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABZ-WU6f3IbxZbH1HpG2Gmex0kANWCHZks5tjQfOgaJpZM4Sle38> .

[BytewaveMLP]

I believe the list of disabled/enabled cards is available here. Any systems with these cards disabled with good reason may be affected, but considering the age of most of these... hm.

[bpasero]

We are building exploration builds that use a much newer version of Electron (our UI framework). I wonder if this issue reproduces with one of these builds, could you try? Download:

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

[methodbox]

@bpasero Thanks! I will try this later today and report back.

[BytewaveMLP]

@bpasero Exploration build is butter smooth with no extra flags. Interestingly, the flickering on mainline Code appears to be reduced in more recent versions without --ignore-gpu-blacklist, but the performance is still just gone.

I dare say, though, that the exploration build is the smoothest Code experience I've seen in a while. Even with all extensions disabled on mainline and with GPU acceleration force-enabled, there's still some noticeable stutter in places (such as terminal refreshing on fast-printing commands like hexdump -C /dev/urandom), and in general it seems to handle comfortably faster. When are we getting this upgraded Electron on stable? 😃

[Ts-OV]

Sadly confirm the similar issues. Unfortunately, reproducible for both UHD and HD monitors.
I have encountered this myself 1st time after updating VC from ver. 1.25 to recent 1.27 on Ubuntu 17.10 (run over XRDP from Xeon Server on HP laptop). However, one of my colleagues was reporting this for VC versions earlier than 1.25. In the latter case this was also U17 but run in VBox on W7 HP laptop.
In my case, 1st of all I tried reinstalling VC packages. This allowed to forget about the issue for about 1 week. After the issues got back, neither the packages reinstall, nor updates (nor re-copy of RDP fixing packages [https://github.com//issues/3451]) helped.
On the other hand, I noticed that the VCode-Insiders didn't have that issue (at least at the moment). I guessed this is caused (in addition to visual perception of what was happening on the screen, where some strange background color rectangular blocks started to appear randomly overlapping [covering, cleaning out] the code window text) by some bug with mouse hover hints pop-ups. I increased the code hints popup delay time and then switched that off completely (although, didn't find how to do the same for full file names pop-ups that appear when mouseovering on top of the file-names shown e.g. in the file list of file browser area or on the top bar of open files tabs). The luck of the VCode-Insiders in this sense seemed to be in the inability to find proper inclusions, so VCode-Insiders wasn't able to show any hint for the code, and hence, no mouseover popups.
Sadly, but disabling the hint popups didn't help the VC. After sometime (even without any mouse moves or visible origin for doing mouse hover triggered actions), the same random background color overlapping rectangles started emerging randomly again, so messing up all the text in the code window (up to 80%).
It doesn't look useful to provide any static screenshots. The videos of what happens might be more useful, if there is no guess from VC developers where the issue might come from..
Just let me know, whether it's needed then. I can shoot the video and post here.
So far, crossing my fingers with hope the VCode-Insiders could work. Otherwise, i'm completely blocked with VC usage for my project development..

[Ts-OV]

Ok. After sometime (probably allowing the corresponding spare processes spoiling text window to finalize), deprecation of mouse over popups really helped.
Next day I tried VC, there were just some VC "nervous" attempts to redraw with background color some several lines below one I was editing at the moment, but then it was able to recover the code text back quite fast.
Only once it showed up with the origin of what probably was causing that.
I seems, there were VC attempts to show some strange typed code context helper popup. But the info on that popup helper was completely illogical and inconsistent! E.g. it was popping up after typing colon symbol in the double slash comment line. Why the heck? What it was supposed to refer to?

Is it a bug?
Are those popups the real cause for messing up the text on the open windows in VC?
Can you please give us a hint which of those can be disabled in VC (in addition to already mentioned found mouse hover related)?

[Ts-OV]

That's how it looks like with no popups blocked:

[Ts-OV]

Also, as the bug description implies, switching VC from full screen mode to windowed of smaller size on UHD monitors seems like allows decreasing the number of residual aftereffects of the mentioned graphics redraw issues.

[bpasero]

We are building exploration builds that use a much newer version of Electron (our UI framework). I wonder if this issue reproduces with one of these builds, could you try? Download:

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

[Ts-OV]

Ok. After waiting for MS IntelliSense to setup (in order to be able showing mouseover popup hints), it looks like I do not see the graphics issues (Linux U17, XRDP) in the corresponding package after playing a little.

[methodbox]

@Ts-OV Can you clarify what you meant by “waiting for MS Intellisense to setup”?

Intellisense is built-in to some extent but there are also extensions to add to this.

Are you using an additional extension for this? Or did you have it disabled previously?

I’m not sure your issue is the same as the rest of us, as per previous posts this hasn’t been inherently tied to Intellisense in any way.

[Ts-OV]

What I meant previously, is VC standard extension (offered automatically by VC to be installed based on C++ project I work currently with):
"
C/C++ | ms-vscode.cpptools | Microsoft
C/C++ IntelliSense, debugging, and code browsing.
"
In addition to the extension standard installation, VC restarting, etc. more or less quick done actions, it needed much more time to build up its some internal (search indexer, etc.) database in order to be able finding the proper sources (includes) fast, to show then the hints for function declared either by mouseover or when intentionally clicked (from right-click menu) "Go to Definition/Declaration".
Until this DB is built, the hints cannot be shown, so there is no normally heavy graphics redraw load when moving mouse over code (no mouseover based popups) and typing at the same time (that also initiates some additional helper popups).
Although, there is no extra graphics redraw load from nonsense typing actions anymore (like for instance, the mentioned previously irrelevant popup when typing colon symbol in double slash commented out line). As well as, I didn't see yet redraws pushed due to some accidental VC IDE decision to apply different code dimming after building up internally another preprocessor #ifdef .. logic understanding.
However, I have seen shortly some new glitch where inclusion selection frame (shown by "Go to Definition/Declaration") stayed after its intentional closing, but text changed to normal view. (Didn't manage to make a screenshot).

[limptwiglet]

@rightaway I'm still seeing this on Ubuntu with i3wm.
It seems to be caused when ever there are splits showing (which the diff has). One way around this (for me at least) is to pass the --disable-gpu-blacklist flag when I start code

[jovere]

@bpasero
I have had the same issue with just a 1920x1080 monitor in ubuntu. The option C_Cpp.dimInactiveRegions turns the entire screen to empty blocks if any large sections of code are dimmed. It looks very similar to the picture from @Ts-OV and even ends up misdrawing the left side panel. I also needed to set the terminal renderer to dom in order for it to be responsive.

However, with the exploration version that was posted a couple weeks ago, those issues appear to be gone. There aren't any empty blocks and the terminal updates very quickly with the default renderer.

[kobalicek]

Affected as well, but this happened after updating nvidia driver (Debian Buster, GTX 1070). Not sure what is the problem, but it means that VSCode is unusable to me. I tried --disable-gpu parameter, but with no luck.

[BytewaveMLP]

@kobalicek

I tried --disable-gpu parameter, but with no luck.

Did you also try --ignore-gpu-blacklist? This at least mostly fixed the issue for me (not entirely, but it's at least usable now).

[kobalicek]

I was only lucky with --disable-gpu --force-cpu-draw arguments. It seems that --disable-gpu is not enough. This is definitely Blink or SKIA issue, VSCode is just a victim in this case :)

[abtrumpet]

@bpasero Thank you for your comments! I have cloned the repo and checked out branch electron-4.0.x. That build actually works beautifully for me. No more flickering at all. Can you tell me, how old/stable is this branch? Does it ever get updated? Would I better off using electron-3.0.x? Thank you.

[mix3d]

Latest build seems to be working well for me too. Have not noticed paint issues in a while. I tried the new TypedArray for the console, but had a crash or two so I disabled it.

[bpasero]

We will not jump from Electron 2.0.x to 4.0.x. Currently we think about shipping 3.0.x in Q1 2019 which means Electron 4.0.x would be somewhere Q2 2019 (just guessing).

[abtrumpet]

Ok, thanks. I will try the electron-3.0.x branch and see how it goes. It generally manages to run better, but I was having issues with it occasionally freezing. Such is the life of HiDPI laptop owner :)

[abtrumpet]

l am on ArchLinux with a dual-graphics laptop (Intel & Nvidia GTX950M). When I run it with just code, it has the repaint issue but when I render on the Nvidia card with primusrun code, the repaint issue seems to be diminished/eliminated. That's using the Bumblebee daemon, of course. So, I'm not entirely sure of the situation that causes this issue.

[bpasero]

Closing this issue given that we plan to release VSCode stable early February with Electron 3.x. If you want to benefit from the fix already, consider to use our insiders version that already contains the fix: https://code.visualstudio.com/insiders/

[cscomfort]

As of this writing, I'm using the latest version of the Insiders build on a MacBook Pro (15-inch, Radeon Pro 560X 4096 MB) + OS X 10.14.1 + Dell P2415Q (DisplayPort / MST Off / 3840x2160 @ 60Hz) and find that the issue still occurs on the external display.

After some additional troubleshooting, I determined that in my case the cause seems to be related to adjusting the Resolution to Scaled in the OS X Display Preference pane. With scaling disabled, I don't encounter the issue.

Note that using a third-party display resolution tool, SwitchResX, seems to allow me to adjust resolution while at the same time avoiding the VSC flicker.

This may prove applicable for some.

[teki]

@cscomfort I have similar issues, reported as a new issue: #68188