extremely slow vector graphic performance

[yope]

System configuration: Virtualbox 1.5.6, 64-bit binary packages on Ubuntu 7.10 host system. Guest system: either Windows2000 or WindowsXP with guest additions installed. Remote desktop connection via rdesktop-vrdp from a linux client connected via 1Gb Ethernet to server.

Problem description: Running some applications that use vector graphics, like CAD systems, is extremely slow. Sometimes it takes several minutes (!!!) to refresh a screen which otherwise would take a split-second to redraw on a "real" PC. On WindowsXP the problem is so severe that sometimes VirtualBox just crashes. During redrawing of the screen the guest system seems totally stalled and unresponsive. I've experienced this problem with "Zuken CadStar express" and running a simulation in Octave with FEMM (The simulation is blazing fast, but redrawing the mesh on screen can take up to 3 minutes!).

Additional information: Running VirtualBox as X-windows client instead of using VRDP, doen't make much of a difference, it is still horribly slow. Doing the test on VMWare-player, it is fast, sometimes about 20-100 times faster that in VirtualBox. Ethernet network load also doesn't make any difference. The speed (or slowliness) varies widely for no apparent reason. Sometimes it is just slow, and sometimes it is very slow. It seems as if drawing time increases exponentially with the complexity of the object that is being drawn, that means that simple drawings most of the time render quickly, whereas more complex drawings go in "bursts", slowing to a crawl somewhere in the middle. It becomes so slow, that you can count the indivitual lines being drawn on screen. All other applications (that do no intense vector drawing on screen) run fine at normal speed, interaction is snappy and even transition effects on menus are quite workable.

[sunlover]

Which graphics backend do you use with Octave: gnuplot or JHandles?

[Edwin Olson]

I'm seeing the same problem using Mentor Graphics PADS (a CAD program). The delays don't amount to minutes, but the performance is conspicuously worse than on a bare-metal machine. Redraws that are essentially instantaneous on a bare machine take about a second.

I'm running virtualbox 1.5.6.

[yope]

Replying to sunlover:

Which graphics backend do you use with Octave: gnuplot or JHandles?

gnuplot backend, but I doubt that this matters in this case, since no plots are drawn, octave just controls femm, which does all drawing.

[yope]

Replying to eolson: Do you use 32-bit or 64-bit VirtualBox binaries? And on what platform? I am wondering if that has any influence.

[Edwin Olson]

I am using 64bit vbox on fedora. I can confirm that the performance problem exists on 1.6.0 as well.

[yope]

Update:

Just upgraded the server from ubuntu 7.10 to 8.04.1 (still 64 bit) and VirtualBox 1.5.6 to 2.0.4, as wel as rdesktop-vrdp from 1.5.0 to 1.6.0 and the situation has not improved the tiniest bit. For instance using Zuken's CadStar viewer 10 to view a layout takes sometimes over a minute to just redraw the screen! What makes things even worse, now I am experiencing redrawing artifacts with some programs that did not occur before the upgrade. Giving the option "-b" to rdesktop-vrdp does not change this.

Note that ethernet network performance is not the problem (Gigabit ethernet with very little traffic besides rdesktop-vrdp).

[yope]

More updates:

I also tried VirtualBox 2.0.4 on a 32-bit machine (ubuntu 8.04.1 32-bit), and there is no difference. It is still painfully slow.

Running the VirtualBox GUI on a local screen (i.e. no VRDP connection), redrawing speed is almost as fast as on a physical windows machine.

P.S.: When will someone from Sun please have a look at this issue? It's starting to look like nobody cares about bug-reports.... If at least I had the source-code to the VRDP stuff, I would try fixing it myself, but it's not Open-Sourced (yet?), so please, someone help me (us?) out!

[Frank Mehnert]

Calm down. Please would you have a look at the list of open bugs: There are currently more than 1000 open and I'm sure there are more important bugs than yours. And yes, I know, you think that your bug is the most important one. But keep in mind: Some bugs need more time to fix than others. And some bugs are easier to reproduce than others.

[yope]

Thanks for reacting.

And sorry for becoming a little impatient. This bug stands open for over half a year already and from what I can see, nobody (from the developers) had reacted until now. The bug hasn't even been assigned to anybody. Please understand that having no reaction at all whatsoever during such a long time is quite frustrating.

I know that there are a lot of open bugs since a long time, and new releases are coming out quickly without the open bug-list becoming noticeably shorter. That also doesn't help very much against user-frustration...

Now that I know somebody is listening, frustration is gone and hope is back :-) Please tell me if I can help somehow. Test some specific application? Make more benchmark tests? Network monitoring? Tcpdump?

[sunlover]

I good testcase, which reproduces the problem, would help. For instance a download link to the Zuken's CadStar viewer 10 (is it free? has it a trial version?) and an attached layout to be viewed.

[yope]

You can download Cadstar Design viewer 10 from this URL:

​http://www.zuken.com/products/cadstar/downloads.aspx

I was thinking about providing a complete VM image with software to test the problem, but since I cannot simply put windows on such a machine and then give it away, I thought maybe I can reproduce the problem using a linux-guest which is freely distributable. Before I spend the time on trying to do so, I'd like to know if it is possible to upload the (rather big) resulting VDI file somewhere for you? Also what do you think are the chances this is reproducible with a completely different guest-OS?

[yope]

An example PCB file to test with Cadstar viewer

[yope]

I just attached an example PCB file which is just complex enough to trigger the problem. How to proceed to recreate our situation:

1. Make a VM with windows 2000 SP4 (should also work on XP or other SP's) on a linux host (tested with ubuntu 8.04.1 both 64-bit and 32-bit). Activate VRDP and start the VM using VBoxVRDP.

2. Connect to the VM using rdesktop-vrdp version 1.5 or 1.6 from a linux guest machine (tested with ubuntu 7.10 and 8.04.1 both 64-bit and 32-bit)

3. Install Cadstar design viewer from the provided link

4. Open the file testcase.pcb (attached to this ticket)

5. Drawing of the PCB layout on screen should start fast and slow down half-ways. Try zooming in and out of different sections.

Our board layouts are much more complex than the provided example, so the problem is a lot more noticeable in our situation, taking somtimes over a minute to redraw (on a physical PC the same redraw would take a fraction of a second). Note that this is not the only application experiencing this problem. It happens also with other "vector-drawing" programs, like FEMM.

[yope]

Just forgot one detail in the description above: Guest additions (2.0.4) were of course installed on windows.

[sunlover]

Thanks for the information. I believe I've reproduced the problem. However the fix requires quite a lot work and therefore will not be available in a near future.

[yope]

Ok, thanks a lot. I'll try to be as patient as possible. Please tell me if I can be of any more help. I suppose the problem is not in the open-sourced part of VB, is it? Would you be able to tell if it's network-related, or guest-driver related?

[sunlover]

It is related to the guest driver. Polygons are drawn as sets of rectangles, instead of a single command. The fix requires new code in both guest driver and VRDP server.

[yope]

Interesting. But shouldn't drawing speed be more or less constant in that case? I clearly see drawing speed go up and down the whole time for no apparent reason. Similar shapes are repainted, some of them paint very fast, and others very slowly. Is that symptom also explained by your findings?

[sunlover]

Yes, these symptoms can be explained too. Drawing speed heavily depends on how many subrectangles a polygon has.

[yope]

Confirmed that this bug is still there in Version 3.2.2 of VirtualBox. Tried with VirtualBox 3.2.2 and winXP as Guest OS, using version 12 of the Zuken Cadstar design viewer.

The following situations give different results:

1.- VirtualBox GUI on local display (no VRDP, no X11 over ethernet): Drawing speed: very fast

2.- VirtualBox GUI on remote X11-display (no VRDP, X11 over network): Drawing speed: very fast

3.- VirtualBox VRDP server with rdesktop-vrdp client: Drawing speed: extremely slow.

Will this ever be fixed? It's been more than 2 years now....

[sunlover]

If you have to use the VM remotely, then as a workaround you could connect directly to the XP guest's embedded RDP server.

For a VM with NAT, port forwarding has to be setup (see UserManual 6.3.1 Configuring port forwarding with NAT).