I'm having what seems to be exactly the same issue, but with bit older Mac where Virtuabox 5.0 was very fast. I'm running latest Virtualbox 6.0.14, with updated extension pack, and latest guest additions. (see attached system information, and virtualbox log)
HiDPI or not doesn't seem to have effect. I believe I've tried everything suggested in this thread, and many of the other similar threads about VBox 6 perf issues on Mac.
Virtualbox 5.x had pretty much native UI speed what came to scrolling text editor, or moving windows. With Virtualbox 6.0 just moving a window lags as if it would be software rendered. However, I've confirmed guest (Ubuntu 16.04) is using SVGA3D, and unity_support_test confirms that it's not using software rendering.
Furthermore, the issue seems to be on host side. When moving a window, guest CPU load seems to stay well below 1% when moving a window, while host CPU load is 150 - 200%.
I took a quick look at Virtualbox host process with profiler where I'm just moving a terminal window in Ubuntu guest. It seems there are hot spots where VirtualBox uses Qt to draw images. In the below image on the left you can see that QRasterPaintEngine::drawImage is taking around 21.6% of the total time, where CPU load in the selected range was on average about 200%. The actual time is spent in QtGuiVbox library (called from drawImage), where QtGuiVBox appears to be doing SW pixel processing. On the right side is shown the heaviest stack trace, which is the same as shown on the left.
- Screenshot from the profiler showing high SW pixel processing load in main thread
- profiler_screenshot.jpg (122.12 KiB) Viewed 21490 times
Another two hot paths are shown below which together take around total 30% of the time. In this case hotspot is in NSView _recursiveDisplayRect*, and in glGetTexImage:
- NSView in main thread and GL thread high CPU load uploading textures
- profiler_screenshot2.jpg (116.71 KiB) Viewed 21490 times
So in total, these three paths account for around 50% of all CPU load, or in this case 100% of one of the host CPU cores.
Any ideas if there's some misconfiguration on my side that causes CPU processing of pixels in QT, or something else that might explain the high host CPU load?