Highlighting, flickering, and rendering graphics display issues

[hermidalc]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.69.0
• OS Version: Fedora 36 (VMware guest VM)

Steps to Reproduce:

1. Upgrade from 1.68.1 to 1.69.0
2. Open a code file and start to try and highlight blocks of code with your mouse
3. After a few seconds of doing this repeated you will get strange flickering and blocking display issues

This appears to be a regression from 1.68.1 since didn't happen on my system with this version, and when I downgrade back to 1.68.1 the problem of course disappears, so doesn't appear to be caused by any very recent Fedora system package updates. In 1.69.0, if I launch with --disable-gpu, then the issue also disappears.

[jeremyn]

This is the same problem that I'm getting on Ubuntu 22.04 that I described in https://github.com/microsoft/vscode/issues/152816#issuecomment-1179023320. Starting VS Code with --disable-gpu also fixes the issue for me. It also works if I set "disable-hardware-acceleration": true as described here in the v1.40 release notes.

I hope this is getting looked at with some urgency. VS Code is still usable with the graphical glitches but it's distracting.

[Boris-Rasin]

Same issue with macOS (12.4) guest in VMware - VS Code 1.69 is completely unusable. Fixed by reverting VS Code to version 1.68.1 or using flag "disable-hardware-acceleration": true (--disable-gpu).

[jeremyn]

VS Code v1.69.1 was just released, however this problem still remains. On the other hand it's not listed in https://github.com/microsoft/vscode/issues?q=is%3Aissue+milestone%3A%22June+2022+Recovery+1%22+is%3Aclosed so I don't think it was supposed to be fixed, either.

Unfortunately, I've started noticing another issue where dropdown menus don't always paint fully when selected. For example if I left-click the "View" option in the menu bar at the top, perhaps it will just display an empty white rectangle. The various options like "Command Palette..." and "Open View..." then appear in blocks as I move my cursor down. If I leave "View" and try again, it might be fully filled out. Sometimes it might only be partially filled out.

This new problem only seems to happen with GPU acceleration disabled, so it's either/or for me to choose which problem I want to have. I can make a new issue for this if the VS Code developers think I should, please let me know.

I want to stress how bad this all is, especially the glitchiness with GPU acceleration enabled. It's only bearable since it just happened and clearly the developers are hard at work fixing emergency issues. If this were ignored or marked as some distant roadmap item I would probably move to a different product.

[hermidalc]

I can't even use 1.69 at all really, they display issues are just too much for my eyes and make it too hard to work. Thankfully 1.68 works

[jeremyn]

The fix of setting "disable-color-correct-rendering": false described in https://github.com/microsoft/vscode/issues/152816#issuecomment-1183033252 does not fix the glitchiness with GPU acceleration, so these really must be different problems.

Also, like @hermidalc and @Boris-Rasin I too am seeing this problem in a VMware guest.

[hermidalc]

The fix of setting "disable-color-correct-rendering": false described in https://github.com/microsoft/vscode/issues/152816#issuecomment-1183033252 does not fix the glitchiness with GPU acceleration, so these really must be different problems.

Also, like @hermidalc and @Boris-Rasin I too am seeing this problem in a VMware guest.

Yeah I'm wondering something that devs changed in 1.69 that doesn't play well with VMware guest GPU acceleration, but 1.68 works perfectly!

[jeremyn]

Both the original problem and the dropdown menu problem I described above in https://github.com/microsoft/vscode/issues/154705#issuecomment-1182208733 are still in v1.69.2.

@deepak1556 I see this issue has been assigned to you. Please let me know if you want me to open another issue for the dropdown menu problem. I don't want to take focus from @hermidalc 's reported problem unless you think they're related or otherwise specifically want to keep them together in this issue for some reason.

[tq-schifferm]

https://stackoverflow.com/questions/72974127/vscode-flickering-disappearing-text-after-upgrade-to-code-1-69-1/72989802#72989802 notes that disabling 3D acceleration in VMware also works around this issue.

Passing --disable-gpu to VSCode seems to be insufficient for the creator of that post however. I wasn't able to reproduce this on my Xubuntu 20.04 guest - --disable-gpu is working here.

With enabled GPU, VSCode 1.69.x is completely unusable on my system. Most text is corrupted:

[deepak1556]

Can users in this thread try out our exploration build which comes with a newer runtime and see if the issue still repros, thanks!

Download links

• MacOS Universal
• Linux x64 Archive
• Windows x64 Archive

[jeremyn]

@deepak1556 It still seems broken to me with the Linux build.

[jeremyn]

Inspired by https://github.com/microsoft/vscode/issues/152816#issuecomment-1183239945: I'm also seeing the problem at https://insiders.vscode.dev using Chrome in the Linux guest.

This whole issue should be trivial to reproduce since it all happens in VM environments anyone can install. Can someone on the VS Code team (@deepak1556 ?) confirm they've been able to reproduce the problem? We definitely should not be in a place where the team has to send out test builds to the community and wait for feedback.

[hermidalc]

Can users in this thread try out our exploration build which comes with a newer runtime and see if the issue still repros, thanks!

Download links

* [MacOS Universal](https://az764295.vo.msecnd.net/exploration/599241ad746b60436371c442f6e5e0341a3e5d5c/VSCode-darwin-universal.zip)

* [Linux x64 Archive](https://az764295.vo.msecnd.net/exploration/599241ad746b60436371c442f6e5e0341a3e5d5c/code-exploration-x64-1658241254.tar.gz)

* [Windows x64 Archive](https://az764295.vo.msecnd.net/exploration/599241ad746b60436371c442f6e5e0341a3e5d5c/VSCode-win32-x64-1.70.0-exploration.zip)

I downloaded it to a temp directory and unpacked it, then ran ./bin/code-exploration, opened a few code files and started highlighting blocks with the mouse I don't see the problem happening, thank you! In 1.69.x it would happen pretty quickly. I hope others can confirm this on their setups. @deepak1556 do you know when these improvements will make it to a general release?

[jeremyn]

I checked again with the Linux build linked above, with "Version: 1.70.0-exploration" and "Electron: 19.0.8" under Help > About, running bin/code-exploration and unfortunately the problem is still there for me after dragging my mouse around for a moment or two on a text file, similar to my report a week ago. I want to emphasize the problem is not subtle, I'm not exaggerating some small flicker.

[hermidalc]

@jeremyn I'm on Fedora 36 VMware guest with the latest updates, just fyi maybe there's something on the Fedora side with mesa version (there were a couple very recent updates) or related where it works for me but not on your Ubuntu

[jeremyn]

@hermidalc After your last comment I checked in Fedora Workstation 36 with the latest updates in a VMware guest, and I'm seeing the flickering in VS Code in both the stable build and the code-exploration test build. Both are about as bad as in Ubuntu.

So, I can't reproduce you seeing it as fixed in Fedora. To be clear, I don't mean to argue, I'm just reporting what I'm seeing.

[hermidalc]

@jeremyn @deepak1556

Here's a video of my Fedora 36 VM desktop. The first VSCode I open is the latest 1.69.2, you will see the highlighting rendering issues. The second VSCode I open is the code-exploration, here you will see that I don't get the issue. Same file opened in each VSCode.

Screencast from 07-26-2022 02:19:54 PM.webm

[jeremyn]

@hermidalc Thanks for providing a video, the glitchiness in the first part is pretty much what I'm seeing what I say it's broken. I hope it helps the dev team understand how bad the problem is.

I'm not sure why we're seeing different things in Fedora. Could you please confirm you're not disabling GPU acceleration with the exploration build? It looks like the exploration build uses a different config file for that, ~/.vscode-exploration/argv.json instead of the usual ~/.vscode/argv.json. The default is to leave GPU acceleration enabled so that shouldn't be an issue, but I don't know what else to suggest.

On my side I'm using a Windows 10 host with VMware Workstation Pro 16.2.4. In the Fedora 36 guest the problem for me happens with the exploration build with both GNOME Wayland and GNOME Xorg. I can check whatever else might help.

[hermidalc]

I'm not sure why we're seeing different things in Fedora. Could you please confirm you're not disabling GPU acceleration with the exploration build? It looks like the exploration build uses a different config file for that, ~/.vscode-exploration/argv.json instead of the usual ~/.vscode/argv.json. The default is to leave GPU acceleration enabled so that shouldn't be an issue, but I don't know what else to suggest.

I can confirm GPU acceleration is not disabled, I never changed the .vscode-exploration/argv.json and checked it's still commented out

On my side I'm using a Windows 10 host with VMware Workstation Pro 16.2.4. In the Fedora 36 guest the problem for me happens with the exploration build with both GNOME Wayland and GNOME Xorg. I can check whatever else might help.

I'm using the same Windows host, VMWare Workstation, and Fedora 36 guest versions. Not sure why it works on my side but not yours. Have you made user to update Fedora to the latest? There were some mesa updates lately, even today, and VMWare GPU acceleration works via mesa.

[jeremyn]

Have you made user to update Fedora to the latest? There were some mesa updates lately, even today, and VMWare GPU acceleration works via mesa.

I did a full update in Fedora before checking VS Code earlier today, and the problem happens for me with the exploration build using mesa 22.1.4-1.fc36 which is the most current stable version according to https://src.fedoraproject.org/rpms/mesa.

[hermidalc]

@deepak1556 I'm sure you've already looked or are looking at this, but wouldn't a good place to start be looking at what you changed in VSCode relevant to rendering between 1.68 and 1.69? It couldn't be that much since it wasn't a major release. This might help troubleshoot the source of the issue.

[jeremyn]

@hermidalc (I hope I'm not being too chatty) The problem probably started because VS Code v1.69 upgraded Electron to v18, see https://code.visualstudio.com/updates/v1_69#_electron-18-update. @deepak1556 tagged this issue electron-18-update. The exploration build has Electron v19 which is probably why @deepak1556 hoped it would fix the problem.

I've looked around a little at https://github.com/electron/electron/issues but couldn't find anything like this reported. I hope the VS Code team doesn't expect us end users to act as middleperson bug reporters between VS Code and Electron.

[hermidalc]

@jeremyn absolutely don't worry about being chatty, that's what GitHub issues and discussions are all about. Every little bit helps them find the source of the problem

[deepak1556]

Neither Electron nor VSCode are responsible for hardware acceleration support, the work is done by chromium. This bug is a usual case were the runtime did not disable hardware acceleration by default for drivers it cannot support using this blocklist. The reason for asking to test with exploration build is to see if newer chromium runtime has addressed it. Looks like it has been addressed with Chromium 104 https://bugs.chromium.org/p/chromium/issues/detail?id=1327939, Electron 19 only uses Chromium 102. I will backport the fix to Electron 19 branch and it will be available with insiders next week.

For now, please continue to use with --disable-gpu or the runtime argument "disable-hardware-acceleration": true as a workaround.

[jeremyn]

@deepak1556 Reading the Chromium bug report carefully it looks like the "fix" is going to be just disabling GPU acceleration by default, meaning I can remove "disable-gpu-acceleration": true from argv.json but acceleration will still be disabled. Is that right?

I can't tell from your comment whether you mean that v1.68.1 already had GPU acceleration disabled automatically or not. I've tried v1.68.1 and v1.69.2 with acceleration manually enabled and disabled. In both versions enabling acceleration seems to make editing feel snappier, though I might be imagining at least some of that, but it's also definitely the case that in both versions, without GPU acceleration, I get the menu painting problem I described at https://github.com/microsoft/vscode/issues/154705#issuecomment-1182208733. (Also please note that I asked in that comment whether I should make a separate issue for that, and didn't get a response.) So acceleration makes an objectively noticeable difference in both versions.

So if you could explain the different behavior between v1.68.1 and v1.69.2 in more detail and the intended behavior with the incoming fix, that would help, because I'm confused.

Also none of this explains why the problem went away for @hermidalc in Fedora 36 with the exploration build that apparently does not have the incoming fix. Any ideas there?

[hermidalc]

@deepak1556 @jeremyn it was very hard to see it, my bad, but even in the video no one saw it. But in the vscode-exploration build you gave yes there are still highlighting graphics rendering issue. See the left vertical lines:

s I just didn't see them the first time around.

[hermidalc]

Neither Electron nor VSCode are responsible for hardware acceleration support, the work is done by chromium. This bug is a usual case were the runtime did not disable hardware acceleration by default for drivers it cannot support using this blocklist. The reason for asking to test with exploration build is to see if newer chromium runtime has addressed it. Looks like it has been addressed with Chromium 104 https://bugs.chromium.org/p/chromium/issues/detail?id=1327939, Electron 19 only uses Chromium 102. I will backport the fix to Electron 19 branch and it will be available with insiders next week.

For now, please continue to use with --disable-gpu or the runtime argument "disable-hardware-acceleration": true as a workaround.

And to push on @jeremyn question, do you mean that 1.68 and the underlying Chromium build inside it already had gpu acceleration hardcoded disabled? Or at least part of the graphics is?

[hermidalc]

@deepak1556 Reading the Chromium bug report carefully it looks like the "fix" is going to be just disabling GPU acceleration by default, meaning I can remove "disable-gpu-acceleration": true from argv.json but acceleration will still be disabled. Is that right?

I can't tell from your comment whether you mean that v1.68.1 already had GPU acceleration disabled automatically or not. I've tried v1.68.1 and v1.69.2 with acceleration manually enabled and disabled. In both versions enabling acceleration seems to make editing feel snappier, though I might be imagining at least some of that, but it's also definitely the case that in both versions, without GPU acceleration, I get the menu painting problem I described at #154705 (comment). (Also please note that I asked in that comment whether I should make a separate issue for that, and didn't get a response.) So acceleration makes an objectively noticeable difference in both versions.

So if you could explain the different behavior between v1.68.1 and v1.69.2 in more detail and the intended behavior with the incoming fix, that would help, because I'm confused.

Also none of this explains why the problem went away for @hermidalc in Fedora 36 with the exploration build that apparently does not have the incoming fix. Any ideas there?

@jeremyn I tried same and manually disabled hardward acceleration on my 1.68.1 and don't notice any difference really. It would be very hard to notice any difference in performance, so I imagine at least parts of VSCode and Chromium already had this hardcoded disabled regardless of what is set in argv.json. I'm continuing with latest 1.69 and onward with it disabled manually until Chromium can get things working because all the same to me really.

[jeremyn]

@hermidalc I created a separate issue https://github.com/microsoft/vscode/issues/156719 for the menu display problem I mentioned earlier. In my case that other problem starts when GPU acceleration is disabled and stops when it's enabled. So even if I'm imagining smoother cursor movements with GPU acceleration on, the menu problem shows me that GPU acceleration definitely has some effect. It's a better problem to have than the graphical glitches this issue is about, though, but it's not all the same to me, since I get one problem or the other depending on whether acceleration is enabled or not.

It would be great to get some guidance from @deepak1556 on all these questions and on the other issue. If the coming patch doesn't fix both problems for me, and based on this discussion I don't think it will, we might want to reopen this issue, or I might make a new one if you want to get out of this one.

[hermidalc]

@jeremyn are you getting the issue #156719 in the clean Fedora 36 guest VM you spooled up?

[deepak1556]

Reading the Chromium bug report carefully it looks like the "fix" is going to be just disabling GPU acceleration by default, meaning I can remove "disable-gpu-acceleration": true from argv.json but acceleration will still be disabled. Is that right?

Yes that is correct.

I get the menu painting problem I described at https://github.com/microsoft/vscode/issues/154705#issuecomment-1182208733

Thanks for creating https://github.com/microsoft/vscode/issues/156719. I have commented in that issue for next steps.

[jeremyn]

I've responded at https://github.com/microsoft/vscode/issues/156719#issuecomment-1201256277 for the menu problem.

@deepak1556 Thanks. Would you please comment here when the automatic disabling fix has made its way into VS Code stable?

Also both @hermidalc and I asked whether Chromium (and VS Code) has always had GPU acceleration automatically disabled in VMware Linux guests. If GPU acceleration is broken in that configuration I would at least expect some issue in the Chromium tracker like "make GPU acceleration work in VMware Linux guests" even if the issue sits there with no activity. @deepak1556 Could you please answer this directly even if just to say you don't know?

[jeremyn]

From the Chromium tracker: issues https://bugs.chromium.org/p/chromium/issues/detail?id=800453 (from 2018) and https://bugs.chromium.org/p/chromium/issues/detail?id=929764 (from 2019) seem relevant. There's this comment from a Chromium project member in the second issue, from 2021, after a year of no activity:

No updates lately; are people still experiencing this issue?

If so, should we consider blocklisting VMWare drivers by default (and using software rendering)?

which is then seconded by another project member. My guess is the Chromium team would accept fixes but no one wants to look into it.

So disabling acceleration by default seems the only real option. Probably the menu display problem isn't directly related, except that it's maybe caused by some display refresh bug that only happens with software rendering. In a way we were lucky that this acceleration bug existed because it let us discover that GPU acceleration fixes the menu problem.

[hermidalc]

Also both @hermidalc and I asked whether Chromium (and VS Code) has always had GPU acceleration automatically disabled in VMware Linux guests. If GPU acceleration is broken in that configuration I would at least expect some issue in the Chromium tracker like "make GPU acceleration work in VMware Linux guests" even if the issue sits there with no activity. @deepak1556 Could you please answer this directly even if just to say you don't know?

I looked back and Chromium has had the VMware graphics issue open since 2018 at least, and since then I can see they’ve only taken the route of blocklisting, so would say good luck with that, not sure if going to have any traction.