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 in other versions of rdesktop, e.g. 1.6.0-0.1.el4.rf as included in RHEL4 (more detail below). Version-Release number of selected component (if applicable): rdesktop 1.6.0-2.fc10 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: My problem system has Fedora 10 installed, Intel 945GME integrated graphics using the intel X.Org driver and rdesktop 1.6.0-2.fc10. An older machine with RHEL4 installed, Intel 915GM integrated graphics using the i810 X.Org driver and rdesktop 1.6.0-0.1.el4.rf has no problems displaying the same vector graphics that take minutes to render on the Fedora 10 machine.
I have the same problem with Labview, but I'm not sure it's directly attributed to vector graphics but it maybe. Same rdesktop, Intel 82945G/GZ integrated controller. Is there an earlier version of rdesktop compiled for F10??
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. I think this is most likely a graphics driver issue so I'm transferring this from rdesktop to the video driver. Unsuable system: 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 Usable system: Intel 915GM graphics Centos 4/RHEL 4 graphics drivers rdesktop-1.6.0-0.1.el4.rf
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), /var/log/dmesg, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Could you take also a look at https://fedoraproject.org/wiki/Common_F11_bugs#Miscellaneous_problems_with_Intel_graphics_adapters and try the workarounds there? Does anyone of them helps?
I don't have an /etc/X11/xorg.conf (so far I'm letting the X server configure itself) and nothing of note ends up in dmesg. I will however attach my current /var/log/Xorg.0.log. I will see if nomodeset and EXA/XAA make any difference, though I won't be able to test them properly until I'm back at work on Monday. Incidentally I should probably point out that I'm using compiz, though disabling it didn't help with F10 so I've no reason to expect that it will help with F11.
Created attachment 349573 [details] Xorg.0.log for 945GME Xorg.0.log as requested
Created attachment 349574 [details] /var/log/dmesg for 945GME /var/log/dmesg as requested
Perhaps I should highlight the fact the this performance regression was if anything even more apparent in F10, and so predates KMS, UXA and DRI2. Whatever the problem is it was, if anything, even worse in the driver versions which shipped with Fedora 10 which did not (by default at least) use any of these things. The fact remains, however, that my 945GME equipped netbook with the latest drivers is not a patch on my antiquated Centos 4/915GM laptop when it comes to rdesktop. The elderly machine runs fine whereas the new machine which sits next to it in my office is unusable.
I think I have the same experience running F11 (intel box) and rdesktopping to a Windows (Vista) system. Things are so superslow that it is entirely impossible to use things such as excel (scrolling a spreadsheet) or Visual Studio (scrolling code or using its code editor). Word and outlook are workable but not fun to use. Please note that all these apps rendered perfectly fine and fast in F9 until I switched over to F11 a few weeks ago. It's been a real royal pain in the butt ever since. It's so bad that whenever I have to do Windows work I unhook the monitor, keyboard and mouse from my linux machine and hook them up to the Windows machine so I can do my Windows work that way. For someone living in a hybrid Linux/Windows world, this is almost impossible to do. As mentioned earlier, rdesktop worked flawlessly through quite a few versions of Fedora. This is the first time it is no longer very usable. I REALLY hope this can get fixed. RR
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I have not done the 'yum upgrade --enablerepo='*-updates-testing' but I am doing my daily (automated) updates. I have seen no improvements over time. I am still unhooking cables and switching them over to my Windows machine whenever I need to work on the Windows side. It's been a lousy experience and I feel sorry for myself ever having updated from F9 to F11. I'll try the 'yum upgrade --enablerepo='*-updates-testing' and see what happens. RR
My system is nightly yum updated. Just tested enabling *-updates-testing and all I would get are some VirtualBox updates. Rdesktop still goes catatonic on most occasions when I run LabVIEW and try to drag large schematics. Graphic card is Intel 82945G/GZ
Are you able to reproduce with LiveCD (you don't have to install anything) from http://alt.fedoraproject.org/pub/alt/nightly-composes/, please? If yes, please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Haven't had this problem since upgrading to Fedora 12 and/or some of the associated x11 drivers. I'd close it
See Comment 12; no changes since; still unhooking cables every time I must run Excel or Visual Studio through remote desktop (unworkably slow). I'm glad that this problem may have been solved in F12 (Comment 16) but I will not be able to move/update until June. This is this still a HUGE problem for me. Still running daily yum updates. RR
After switching from F10 to F12 on a PC with nVidia Corporation NV44 [GeForce 6200 LE] and 82801G / 82945G/GZ/P/PL chipsets I can see problems when scrolling text cmd windows on a Windows server connected to via rdesktop. I normally create a shortcut to cmd with 105 x 40 windows size and long history buffers; When no text is selected in such cmd windows, scrolling is fast; However, when I need to select some text larger than cmd windows with mouse, so I select what is visible in that cmd window and then drag mouse below the cmd window to extend selection, the scrolling is extremally slow, with selected area blinking slowly on and off, local Xorg consuming about 100% CPU and the KDE is becoming almost unresponsive for some time. I have not seen this problem while running Fedora10 on the same machine or CentOS5 on other, much slower machine. Could possibly some people using rdesktop on Fedora10 - Fedora12 check this on your machines?
(In reply to comment #18) > After switching from F10 to F12 on a PC with > nVidia Corporation NV44 [GeForce 6200 LE] > and 82801G / 82945G/GZ/P/PL chipsets > I can see problems when scrolling text cmd windows > on a Windows server connected to via rdesktop. > > I normally create a shortcut to cmd > with 105 x 40 windows size and long history buffers; > When no text is selected in such cmd windows, > scrolling is fast; > However, when I need to select some text > larger than cmd windows with mouse, so I > select what is visible in that cmd window > and then drag mouse below the cmd window to extend selection, > the scrolling is extremally slow, with selected > area blinking slowly on and off, local Xorg consuming about 100% CPU > and the KDE is becoming almost unresponsive for some time. > I have not seen this problem while running Fedora10 on the same machine > or CentOS5 on other, much slower machine. > > Could possibly some people using rdesktop on Fedora10 - Fedora12 > check this on your machines? Same issue here. I'm connecting via RDP to Windows Server 2003. The client is rdesktop on FC12. When cmd.exe window is awaiting input, local Xorg consumes entire cpu core.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I've finally upgraded to Fedora 13 and unfortunately severe performance problems are still present for vector graphics via rdesktop. While 'minutes' to redraw would now be an exaggeration I have timed a single screen refresh at 27 seconds when a ZEMAX layout diagram (nothing more than simple wireframe graphics) was on screen, which make this remote application unusable from my laptop. System details: Intel 945GME graphics xorg-x11-drv-intel-2.11.0-5.fc13.i686 mesa-dri-drivers-7.8.1-6.fc13.i686 kernel-2.6.33.5-131.netbook.fc13.i686 libdrm-2.4.21-2.fc13.i686 rdesktop-1.6.0-7.fc12.i686
Created attachment 435453 [details] Fedora 13 Xorg.0.log for 945GME This is my Xorg.log from the laptop exhibiting this problem under Fedora 13, in case it helps.
Created attachment 435469 [details] Fedora 13 /var/log/dmesg for 945GME Dmesg from Fedora 13 on the problem laptop, as this has been asked for previously.
(In reply to comment #24) > Created an attachment (id=435469) [details] > Fedora 13 /var/log/dmesg for 945GME > > Dmesg from Fedora 13 on the problem laptop, as this has been asked for > previously. Yes, thank you very much. It would be actually even more useful to get OUTPUT of the command dmesg AFTER the problem happens. /var/log/dmesg is just a dump of dmesg from startup and it is not that useful for our problem. Thank you very much and thank you for the patience with rdesktop.
I just upgraded from FC11 to FC13. I'm happy to say that rdesktop is once again functioning properly.
Reporter, could you confirm the comment 26? Did this get better in the latest updates to F13? Thank you
Just to reconfirm. I just did an install of FC13 (kernel 2.6.34.7-61.fc13.i686.PAE) and rdesktop to a Windows Vista machine is working nicely. RR
Re: comment 26, I have tested again following the recent DRI and kernel updates. Potentially relevant software versions: kernel-2.6.34.7-61.fc13.i686 xorg-x11-drv-intel-2.11.0-5.fc13.i686 mesa-dri-drivers-7.8.1-9.fc13.i686 libdrm-2.4.21-2.fc13.i686 rdesktop-1.6.0-7.fc12.i686 I don't have a convenient way to quantify the vector graphics performance but I would say it has improved, and while I still consider it to be poor compared when there are no vector graphics on screen rdesktop is now usable most of the time. When I get an opportunity I will try a side by side comparison with my old CentOS Intel 915GM laptop to confirm whether the latest updates have brought the performance of the Fedora 13 Intel 945GME back to a comparable level. Re: comment 25, at no point have there been any entries appearing in the dmesg command output (or /var/log/messages, or /var/log/Xorg.log) when the problem occurs. Whatever the cause of the vector graphics performances issues has been it hasn't been generating any error messages or warnings in the normal logs. I only attached /var/log/dmesg because it had been requested in comment 3.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.