A VirtualBox display adapter bug, and a workaround

[LavieS]

My suggestion is in the second paragraph. Before reading it, I recommend you first read this background information: I'm new to VirtualBox; I installed it a couple months ago (on a Windows Vista 32 host with nVidia 8550GT video card) and immediately had problems with slow video performance in the Linux64 and Vista32 guests I created. For example, simply moving the mouse in a vm window used about 15% of the host's cpu. For another example, VLC in a guest displayed only a white rectangle instead of the video content. I eventually found the problem, and a simple workaround. The problem is that the only color depth option of the virtual display adapter is 32 million colors, but that seems to be performance-incompatible if the host display adapter isn't also set to 32 million colors. Many years ago I had set the nVidia 8550GT to 16 million colors, thinking my eyes wouldn't notice the difference and it would increase video speed. When I changed the nVidia back to 32 million, the video performance problem of the guest virtual machines went away.

So here's my suggestion: MAKE THE DEFAULT SETTING OF THE COLOR DEPTH OF VIRTUAL MACHINES' DISPLAY ADAPTERS EQUAL THE COLOR DEPTH SETTING OF THE PHYSICAL DISPLAY ADAPTER (and perform properly at that color depth, of course). If you want even more sophistication, implement an option to automatically change the color depth of virtual display adapters to match whenever the color depth of the physical display adapter changes.

Thanks for considering it. If Oracle fixes the bug, it may spare some other VirtualBox users from a big headache. I spent a lot of hours researching online without finding anything that helped, before I lucked out and discovered the problem myself. I was nearly ready to abandon VIrtualBox.

[socratis]

Interesting that you seem to be the first one to suffer from this, usually users have the exact opposite, where they use higher bit-depth color in the host and lower in the guest. In any case, the end result is the same; some translation (or a lot of translation actually) has to happen between the host and the guest. The usual advice is to use the same bit-depth on the host and the guest.

I'm not sure if what you're proposing is easily doable, or if it could apply to guests that haven't been envisioned yet. And these days I don't think that too many people do not use "true color", i.e. 32-bit depth color, either in the host or the guest.

[LavieS]

At the very least, shouldn't the user manual advise setting the color depths to match?

[Martin]

This doesn't seem to be a problem for many users. Otherwise we would have seen it much more often and earlier.
My guess is that your hw / sw combination show a much bigger impact than others. There are probably not so many users out there still using Vista 32 with Nvidia.
I wouldn't consider this a "bug", as all the functionality is working, just with a performance impact because of virtualization.

[michaln]

So here's my suggestion: MAKE THE DEFAULT SETTING OF THE COLOR DEPTH OF VIRTUAL MACHINES' DISPLAY ADAPTERS EQUAL THE COLOR DEPTH SETTING OF THE PHYSICAL DISPLAY ADAPTER (and perform properly at that color depth, of course).

The guest OS initially does not have any idea what color depth the host is using. The host color depth is also not something fixed, and with multiple monitors and remote access, a single "host color depth" doesn't necessarily exist at all.

Thanks for considering it. If Oracle fixes the bug, it may spare some other VirtualBox users from a big headache. I spent a lot of hours researching online without finding anything that helped, before I lucked out and discovered the problem myself. I was nearly ready to abandon VIrtualBox.

This isn't a bug, it's a fact of life. You could also complain that your hard disk runs out of space or that downloading huge files takes time.

There used to be warnings about mismatched color depth in the GUI but it triggered so often that it on balance caused more confusion than help. You clearly have an unusual system where the color depth mismatch causes a much bigger performance hit than usual, but do not take that to mean that everyone has the same problem.

[socratis]

Many years ago I had set the nVidia 8550GT to 16 million colors, thinking my eyes wouldn't notice the difference and it would increase video speed.

I believe that you might have made a wrong assumption here. What you would have done by that move is to decrease the video RAM requirements, not the video speed; you'd still have to "move" the same amount of pixels. In fact it would make it slower, due to the 24- to 32-bit translation that would take place almost all of the time, because most programs these days work in 32-bit color. Or assume that they do.