Description of problem:
rdesktop's rendering performance when vector graphics are present is extremely
slow, to the point of making rdesktop unusable. Performance is good when only
text and bitmap graphics are being displayed by the remote Windows machine but
when I run an application which uses vector graphics (in my case ZEMAX)
redrawing of windows becomes very slow. It can take up to several minutes for
a single vector graphics window to redraw, during which time the remote system
will be completely unresponsive and rdesktop will be using 100% CPU on the
local machine. You can actually see diagrams being drawn one line at a time.
A variety of engineering/scientific software uses vector graphics for display
of diagrams/plots/drawings/etc. but while this performance issue remains they
are essentially unusable over an rdesktop connection.
This problem is not present with older software.
How reproducible: Always
Steps to Reproduce:
1. Connect to a Windows server using rdesktop
2. Open a application which uses vector graphics (e.g. ZEMAX, free demo version
available from http://www.zemax.com).
3. Display some vector graphics (e.g. ZEMAX 3d layout or spot diagrams)
Each redraw of a window including vector graphics is extremely slow.
Redraws of vector graphics windows take comparable times to bitmap
This is still an issue on this hardware with Fedora 11. There appears to be
some improvement in performance compared to F10, however the redraw time for a
rdesktop connection to a vector graphics using application with current drivers
and 945GME hardware is still at least an order of magnitude slower than the
same application when viewed from a 4 year old 915GM laptop running Centos 4.
This performance regression is so severe as to make rdesktop unusable for
vector graphics using applications.
Unsuable system (Asus EeePC 901 w/ F11):
Intel 945GME graphics
Intel 915GM graphics
Centos 4/RHEL 4 graphics drivers
>> This problem is not present with older software.
Can you provide the specific version of "older software", e.g. xf86-video-intel, xserver, and kernel.
Created attachment 27211 [details]
Xorg.0.log from older 915GM system which does not exhibit the problem
(In reply to comment #1)
> >> This problem is not present with older software.
> Can you provide the specific version of "older software", e.g.
> xf86-video-intel, xserver, and kernel.
The older software is very much older I'm afraid, but it's the only system I have readily available for comparison. I'm wary about updating as it is currently the only system I have that handles rdesktop w/ remote ZEMAX properly.
It's a Centos4 machine, 915GM hardware, monolithic X.Org:
X.Org 6.8.2 uses the i810 driver module, version 1.3.0.
I've attached the Xorg.0.log from this older system for full module version information.
Created attachment 27212 [details]
Xorg.0.log from newer 945GME system which does exhibit the problem
Here is the Xorg.0.log from the system which does have the problem (Asus Eee PC 901, 945GME graphics, Fedora 11). I'm not using an /etc/X11/xorg.conf at present, I'm allowing X.Org to automatically configure itself.
Anthony, this is complicated by the requirement of a Windows machine...
In order to understand the problem can you capture an xtrace of the traffic rdestop is sending, and in particular how this changes between bitmap and vector apps?
The description seems to imply that we are hitting severe fallback ping-pong for which a plain fb would indeed be measurably faster. Without any information to ascertain the nature of the fallback, it is impossible for us to fix it. However, I do hope the improvements we have made to i915 accelerated performance should alleviate this issue. Please do reopen this bug report if you can show which pathways are at fault - a profile from of the driver should be enough for us to work out what is going on.
Closing resolved+invalid, no activity on more than 6 years.