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) Actual results: Each redraw of a window including vector graphics is extremely slow. Expected results: Redraws of vector graphics windows take comparable times to bitmap graphics/text/etc. Additional info: 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 xorg-x11-drv-intel-2.7.0-7.fc11.i586 mesa-dri-drivers-7.5-0.14.fc11.i586 kernel-PAE-2.6.29.5-191.fc11.i686 libdrm-2.4.6-7.fc11.i586 rdesktop-1.6.0-4.fc11.i586 xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586 Usable system: Intel 915GM graphics Centos 4/RHEL 4 graphics drivers rdesktop-1.6.0-0.1.el4.rf
>> 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: kernel-2.6.9-78.0.13.EL xorg-x11-6.8.2-1.EL.52 rdesktop-1.6.0-0.1.el4.rf 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.