Same problem here with Workstation Pro 15.0.4 build-12990004 and vmware tools 10.3.2 build-9923505 running windows 10 guest and chrome 74.0.3729.131
The faulty rendering goes away if I turn hardware acceleration off in chrome, but that's not a solution because I'd like to use the hardware acceleration.
Could someone from the vmware team please investigate this misbehaviour?
I am not sure whether you were able to figure it out but I recently had the same issue so I did this and it addressed the problem:
1. Open Settings from the Chrome menu (top right of browser window).
2. Search for "hardware" and then disable the "Use hardware acceleration when available" setting.
This bug is still present in Workstation 16.2.0 Pro and VMware tools 11.3.5-18557794
It is not present when installing/downgrading to VMware tools 11.1.5-16724464.
Please note! It is NOT a solution to disable hardware graphics acceleration in chrome because I want and need hardware graphics acceleration.
And the bug shows up in standalone clients like nextcloud client for windows, which seems to be based on the chromium rendering engine.
Interestingly, Microsoft Edge (another chromium fork) does not suffer from this bug. I agree with level420 that disabling 3D acceleration is not acceptable which every solution to date does either through settings, flags, or CLI as evidenced by chrome://gpu.
Did you try changing the ANGLE graphics backend to OpenGL as mentioned here
Go to chrome://flags/#use-angle
It is likely there are many different factors at play here such as host graphics cards and host OS. I don't encounter that problem with a Linux host with Nvidia GPU in a Windows 10 VM with Chrome. Several years back, there was another post that has the white background problem with a Windows host with Intel GPU. The problem goes away if Workstation Pro/Player is switched from used DX11 to OpenGL. But that is a different workaround than the ANGLE workaround; but it does let you keep the hardware acceleration turned on in Chrome.
In the vmx of the VM, shutdown the VM BEFORE adding these lines
mks.enableDX11Renderer = "FALSE"
mks.enableOpenGLRenderer = "TRUE"
Changing the ANGLE backend to OpenGL only "fixes" the issue by disabling hardware acceleration completely as evidenced by chrome://gpu. Similarly, changing the MKS renderer in the vmx file to OpenGL has the same effect (Yes, of course I made the change while the guest was shutdown). This is further verified when vmware-vmx.exe and mkssandbox.exe no longer appear in the NVidia Activity monitor. A windows guest on a windows host must use DirectX in order to achieve 3D acceleration as stated in the following articles (and elsewhere in the community):
Thank-you for your diligence.
Just to be clear, every solution proposed here or elsewhere on the Internet (without exception), that remedies the visual anomaly seen at the top of this thread, also produces the following results when browsing to chrome://gpu on a Windows 10 guest hosted on Windows 10 running VMware Workstation 16 Pro:
According to the following bug report, chromium developers had knowledge of the problem since early 2019 and decided to blacklist the vmware SVGA driver citing time contraints, ultimately concluding it was incompatible with GPU acceleration. Curiously though, as I stated earlier, my tests indicate Microsoft Edge is not affected by the problem, suggesting their team actually found a viable workaround.
What is the GPU on your host? If your GPU does not support OpenGL 4.x that could be the reason why hardware acceleration becomes disabled on the VM (and as a consequence on Chrome) when switch is made to GLRenderer. What is the virtual hardware version of the VM? You might need at least version 12. I never ever tried GLRenderer on Windows host that before version 12.
I don't know where the root of the problem lies. This problem has been around for some time (maybe since version 12.5.x, could be earlier) but does not seem to have affect all configurations (host GPUs). The reason I stumbled on the OpenGLRenderer workaround was the problem did not show up when running on Fusion on MacOS did not exhibit those problems (at that time Fusion was still using OpenGL renderer to deliver DX10/OpenGL 3.3 on Windows VMs, current version now use only Metal). The problem also does not show up on VMs running on Linux hosts as Workstation Pro/Player uses GLRenderer for accelerated graphics.
Hardware Compatibility is Workstation 16.x. My GPUs are NVidia Geforce GTX 1050Ti and Intel HD Graphics 630. Both of them support OpenGL 4.x and I can reproduce the problem using either one. However ANY GPU on a Windows 10 host running VMware Workstation 16 Pro with a Windows 10 guest will exhibit the problem in Google Chrome. I challenge you to submit any reproducible configuration meeting the above criteria that solves the problem very clearly defined in my third post. The other configurations and platforms you cited are irrelevant to this issue.
You're correct, it has existed for far too long as it affects hundreds, if not thousands of users with and without support agreements. VMware developers should have addressed it by now since Chromium developers have clearly identified the VMware SVGA driver as the root of the problem (per my fourth post). Notice that I personally did not initiate this thread, and modest amount of Google searching will reveal numerous reports of the same issue encountered worldwide. I simply use an alternate browser in my Windows VMs due to the bug, and I imagine many others do the same. However, it's time someone compelled VMware to acknowledge and accept responsibility for it choosing either to devote resounces towards a solution, or to take the hit and let it ride.
I don't get that problem (white screen, rendering problemsw with Chrome) with a laptop with Skylake CPU HD630 with GTX 960M on a Windows 11 Home host. Switching to GLRenderer for VMware Workstation also does not disable 3D acceleraton (i.e. mks-sandbox.exe still appears on GPU Activity and Chrome inside still has "Hardware Acceleration"). With laptops, Nvidia Control Panel lets you choose a Default graphics processor so there is no need to use mks.dx11.vendorID to choose. With Intel HD630 as default and OpenGL renderer in the vmx, the horrible rendering problems even with Windows logon/menus still occur though.
So it is strange that once you switched to GLRenderer that the Nvidia GPU is not being used and 3D acceleration is disabled (hence disables Chrome graphics acceleration). Unless the vmx entries you added resulted in disabled DX11renderer and the GLRenderer was not enabled (typo error perhaps??)
As I said, I don't know where the root cause of the problem. If the problem was solely on the SVGA driver, how does that explain it does not seem to happen on Windows VMs that run on Workstation on Linux hosts and macOS Fusion? Just relying on Chromium developer comment also does not explain why it does not happen to your Edge browser. There was another recent post where the user encountered render problems with Opera, Brave and Viber. Both Opera and Brave are also Chromium-based. Viber appears to be written using Qt framework (therefore using ANGLE). So it may not be just Chrome/Chromium specific but rather with ANGLE and/or combination when VMware Workstation Pro/Player uses DX11Renderer (which probably explains why VMware users with Linux hosts and macOS Fusion users does not seem to encounter the Chrome render problems) and generally using the GLRenderer on Windows 10/11 host works around the problem.
Are you validating your results by browsing to chrome://gpu? Just because the switch enabling hardware acceleration in the advanced section of Chrome's settings is ON does not necessarily mean that Chrome is actually using hardware acceleration. Additionally, I haven't found any VMware documentation offically stating that 3D acceleration on a Windows host/guest configuration is even possible using OpenGL. In fact, the following article suggests exactly the opposite. Again, just because the setting exists in the vmx file doesn't mean the functionality is there to back it up.
Operating Systems are vastly different. Stating that a driver should work on one OS because it does on another is ludicrous. The scope of this problem is defined (at a minimum) as a Windows 10 guest on a Windows 10 host running VMware workstation 16 Pro, period. A successful test on that configuration must demonstrate hardware acceleration in Chrome by browsing to chrome://gpu without exhibiting the visual anomaly.
Yes, I also look at chrome://gpu. Same with edge://gpu If you notice with edge://gpu changing the use-angle to OpenGL does not make a difference in the GL_RENDERER in the VERSION INFORMATION section of edge://gpu
Using GLRenderer for Windows 10/11 hosts is not officially supported. As I had already mentioned, I only stumbled upon it because at that time I also had Fusion 8.x (which used OpenGL) running with MacBook Pro with Iris Pro 5200. Fusion 12.x now exclusively uses Metal. On Linux hosts, GLRenderer is still used as the default although VulkanRenderer should also be an option with version 16.x. Some of the code is shared between the 3 different platforms. As it is GLRenderer is still available for Linux hosts, the code should work as well for Windows hosts. Of course one cannot expect the Metal options to work for Linux/Windows or DX11 to work for Linux/macOS hosts.
As GLRenderer on Windows hosts is not officially supported, one would also accept the risk that there could be other problems/side-effects encountered (like rendering problems like Windows VM logon/menus with the HD530/GLRenderer combination).
I just find it strange in your case the VM 3D acceleration graphics gets disabled when you disabled the DX11Renderer. A possible explanation is GLRenderer was not enabled (maybe because of typo error???). Anyway here is the mks-sandbox.log entries with a GTX960M on Windows 11 host using GLRenderer. The GPU Activity show mkssandbox.exe as active and 3D acceleration remain enabled in the VM (and as consequence Chrome as well in the chrome://gpu).
mks MKS Win32: MIL: 0x2000
mks MKS-RenderMain: PowerOn allowed GLRenderer
mks MKS-RenderMain: ISB not enabled by config
mks MKS-RenderMain: Collecting RenderOps caps from GLRenderer
mks MKS-RenderMain: Starting GLRenderer
mks GLHostWin32: : Created context with GL 2.1, core: 0, robust: 0
mks GLHostWin32: : Created context with GL 4.0, core: 0, robust: 1
mks GLRenderer: OpenGL Version: "4.6.0 NVIDIA 496.13" (4.6.0)
mks GLRenderer: OpenGL Vendor: "NVIDIA Corporation"
mks GLRenderer: OpenGL Renderer: "NVIDIA GeForce GTX 960M/PCIe/SSE2"
mks GLRenderer: Driver Version: "4.6.0 NVIDIA 496.13" (496.13)
mks GLRenderer: GLSL Version: "4.60 NVIDIA" (4.60.0)
Which MKS renderer I use is not the issue here because neither of them work. GL doesn't because, as you say, it is not supported in a Windows 10/11 host/guest configuration. The DX renderer loads but forces one to choose between the visual defect in Chrome or no GPU acceleration at all. I don't need to make a case because the sheer volume of users affected by the bug already have. This has been amazing, but I'm quickly losing interest. Our dialouge will provide insight to others who seek answers and perhaps even a degree of satisfaction. Who knows, maybe we've stirred the waters enough to prompt real action. Thank-you for the opportunity to represent.
I also have to agree with you that disabling hardware acceleration is not an acceptable "workaround". Heck I wouldn't even consider that suggestion a workaround since it's such an important feature for many apps. Wanted to say thanks for leaving this comment as it infact helped me "fix" the issue by enabling me to leave hardware acceleration on, but not have the white screens of chromium. That being said, I can't believe it's been this long since this has been an issue and it has not yet been fixed, especially since it seems that an older version of VMware tools seems to not have this issue. I can also confirm that using version 11.1.5-16724464 works on windows 11 as well. I was having this same issue on a windows 10 host with both a windows 10 virtual machine and windows 11 virtual machine no matter what OS updates were installed on either VM, and this version of drivers fixes this issue on both while still seeming to keep functionality of hardware acceleration.
Thank-you for lending that very important point, one which I completely forgot to mention. My initial investigation produced many such reports of the bug's appearance loosely coinciding with the release of Workstation 16 / VMware Tools 11.2, further pinning responsibility squarely on the shoulders of VMware developers. Regardless, we need only ask which of the two concerned parties (VMware or Chromium) bears the greater burden of maintaining compatibility with the other? One reasonably expects a virtual desktop to look, feel, and perform in every way possible like the actual desktop upon which it's hosted. Any incongruency falls short of that ideal and deserves elucidation.
For myself, I am having this issue on a win10 VM Workstation, running on a windows 7 box. Problem shows up for both Brave browser and MS Edge browser (v95).
This is not an issue where there is a decent workaround (without making unusual changes). People are not able to work if they are not able to read any pop up window or their bookmarks.
Today I've realized that version 12.0.0. of VMware Tools are available at https://customerconnect.vmware.com/en/downloads/info/slug/datacenter_cloud_infrastructure/vmware_too... but the bug is still present on my Windows 10 LTSC 2021 x64.
So I'm still stuck on VMware Tools 11.1.5 which do not show the bug.