Video weirdness after upgrading VMware.
After accidentally "upgrading" VMware - which I try to avoid doing over the last couple of years - to the latest version (17.6.3 build-24583834), I was shocked* to discover that Broadcom have introduced more bugs.
In this version, when SoftGPU is installed, the screen behaves weirdly, seemingly never updating until a key is pressed. There may be other events like switching away and switching back or resizing the screen that cause an update, but as a general rule something needs to "trigger" a screen update, moving or clicking the mouse doesn't seem to cause an update so it seems like the VM is running slowly or erratically, but it is actually just the screen failing to update.
Fortunately, editing the .vmx file and adding in virtualHW.version = "19" seems to fix the problem, so this bug-report is partly a PSA. I don't know if there's anything you can do to fix what appears to be yet another VMware bug, but there is this seemingly effective workaround.
*not really
Hello, thanks.
I saw, that screen update was a bit lazy but I attributed this behaviour to GPU drivers (because on NVIDIA GPU and Intel GPU refresh rate look diferent). My driver sending screen refresh command when something is updated, but when this is ignored by VMware now, I have two option - remap screen to RAM what is problem on Win9x due RAM limitation or disable all 2D screen acceleration and works it as with generic framebuffer.
Personally, I would rather not use VMware because I feel that their bug rate is much higher than VirtualBox. In addition, bugs can be fixed in VirtualBox, although Oracle takes about 3 months to take note of your patch, but it is possible.
Anyway, thanks for the discovery and I'll try to fix it somehow.
Sorry for using VMware, I agree it's shite. The thing that holds me back is the complete lack of any system integration whatsoever in any other VMs on Windows. SoftGPU solves part of the problem for QEMU and VirtualBox but annoyances like the mouse being locked inside the VM and quality of life improvements like drag and drop in VMware vs having to make and manage virtual CD images in VirtualBox make it far better from a usability perspective. I'm not really worried about it, and as I said there's a workaround that mostly solves the problem. If I were you, I think I'd just point people at the workaround, perhaps there's some way you could detect what "hardware revision" is in use and give an error suggesting that they edit their vmx file. :)
Frankly upgrading VMware to something after 16.1.2 seem pointless to me.
That said, speaking about VMware v.s. Virtualbox when one sees VMware doing 40/50 fps in 3dmark 2001 and the latest Vbox doing 3/4 fps, there is little room to discussions about which one is better, then vbox is good enough in a lot of non multimedia/gaming scenario.
But, especially on windows host the last Vbox is worse than VMware 10 which is more than a decade old.
Just jumping in to say that virtualHW.version = "19" isn't fixing this for me, only installing older versions of VMware.