VirtualBox

Ticket #1435 (new defect)

Opened 7 months ago

Last modified 2 hours ago

extremely slow vector graphic performance

Reported by: yope Assigned to:
Priority: major Component: RDP
Version: VirtualBox 2.0.4 Keywords: vector graphics slow
Cc: Guest type: Windows
Host type: other

Description

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.

Change History

(follow-up: ↓ 3 ) 04/22/08 17:45:56 changed by sunlover

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

(follow-up: ↓ 4 ) 04/29/08 22:57:35 changed by eolson

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.

(in reply to: ↑ 1 ) 05/06/08 19:34:01 changed by 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.

(in reply to: ↑ 2 ) 05/06/08 19:38:31 changed by 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.

06/11/08 12:58:34 changed by eolson

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

08/18/08 21:08:32 changed by frank

  • priority changed from critical to major.

11/18/08 20:53:30 changed by 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).

11/18/08 21:03:26 changed by 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!

11/18/08 21:23:12 changed by frank

  • owner changed.
  • component changed from other to RDP.
  • guest changed from other to Windows.

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.

11/19/08 19:46:44 changed by 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?

11/20/08 10:54:27 changed by sunlover

  • version changed from VirtualBox 1.5.6 to VirtualBox 2.0.4.

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.

© 2008 Sun Microsystems, Inc.
ContactPrivacy policy