Bug 486065 - rdesktop window redraws take minutes when vector graphics present
rdesktop window redraws take minutes when vector graphics present
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
13
All Linux
low Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
card_945GME
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-17 23:13 EST by Anthony Horton
Modified: 2011-06-27 10:06 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 10:06:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log for 945GME (32.10 KB, text/plain)
2009-06-26 12:21 EDT, Anthony Horton
no flags Details
/var/log/dmesg for 945GME (34.88 KB, text/plain)
2009-06-26 12:23 EDT, Anthony Horton
no flags Details
Fedora 13 Xorg.0.log for 945GME (232.29 KB, text/plain)
2010-07-29 23:55 EDT, Anthony Horton
no flags Details
Fedora 13 /var/log/dmesg for 945GME (35.52 KB, text/plain)
2010-07-30 01:58 EDT, Anthony Horton
no flags Details

  None (edit)
Description Anthony Horton 2009-02-17 23:13:56 EST
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.
Comment 1 Henrique Martins 2009-03-06 14:43:18 EST
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??
Comment 2 Anthony Horton 2009-06-26 08:53:54 EDT
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
Comment 3 Matěj Cepl 2009-06-26 10:52:27 EDT
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.
Comment 4 Matěj Cepl 2009-06-26 10:54:19 EDT
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?
Comment 5 Anthony Horton 2009-06-26 12:19:09 EDT
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.
Comment 6 Anthony Horton 2009-06-26 12:21:12 EDT
Created attachment 349573 [details]
Xorg.0.log for 945GME

Xorg.0.log as requested
Comment 7 Anthony Horton 2009-06-26 12:23:50 EDT
Created attachment 349574 [details]
/var/log/dmesg for 945GME

/var/log/dmesg as requested
Comment 8 Anthony Horton 2009-06-26 12:47:44 EDT
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.
Comment 9 rene reitsma 2009-09-14 19:46:34 EDT
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
Comment 11 Matěj Cepl 2009-11-05 13:22:10 EST
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.]
Comment 12 rene reitsma 2009-11-05 13:34:22 EST
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
Comment 13 Henrique Martins 2009-11-05 15:53:08 EST
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
Comment 14 Matěj Cepl 2009-11-08 19:26:49 EST
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.
Comment 15 Matěj Cepl 2010-02-26 07:23:30 EST
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]
Comment 16 Henrique Martins 2010-02-26 10:09:31 EST
Haven't had this problem since upgrading to Fedora 12 and/or some of the associated x11 drivers.  I'd close it
Comment 17 rene reitsma 2010-02-26 21:49:04 EST
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
Comment 18 Wojciech Pilorz 2010-03-24 05:39:09 EDT
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?
Comment 19 veng 2010-03-24 13:44:54 EDT
(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.
Comment 20 Bug Zapper 2010-04-27 09:00:38 EDT
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
Comment 21 Bug Zapper 2010-06-28 07:18:46 EDT
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.
Comment 22 Anthony Horton 2010-07-29 23:50:13 EDT
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
Comment 23 Anthony Horton 2010-07-29 23:55:05 EDT
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.
Comment 24 Anthony Horton 2010-07-30 01:58:04 EDT
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.
Comment 25 Matěj Cepl 2010-07-30 14:08:20 EDT
(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.
Comment 26 rene reitsma 2010-08-09 18:23:39 EDT
I just upgraded from FC11 to FC13. I'm happy to say that rdesktop is once again functioning properly.
Comment 27 Matěj Cepl 2010-10-27 11:23:15 EDT
Reporter, could you confirm the comment 26? Did this get better in the latest updates to F13?

Thank you
Comment 28 rene reitsma 2010-10-27 11:47:22 EDT
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
Comment 29 Anthony Horton 2010-10-31 22:58:31 EDT
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.
Comment 30 Bug Zapper 2011-06-02 14:15:54 EDT
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
Comment 31 Bug Zapper 2011-06-27 10:06:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.