Closed Bug 475713 Opened 16 years ago Closed 14 years ago

slow performance with xdmcp

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
3.0 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: miek, Unassigned)

References

Details

(Whiteboard: [CLOSEME 2010-11-01])

Attachments

(1 file)

XREQUEST trace FF3
48.49 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; nl; rv:1.9.0.4) Gecko/2008103100 SUSE/3.0.4-4.7 Firefox/3.0.4 We have a remote X session running with XDMCP, almost all application run fast. Even a youtube video is running normally (in FF) over this XDMCP session. This is on a gigabit network. There is one MAJOR problem, the responsiveness of firefox is unbearable. If you right click on a webpage (to get the 'back', 'forward' menu) you have to wait about 2 seconds before the menu pops up. This is even more strange while you are looking a streaming video on youtubte (which runs very smoothly). Also the menu is also slow to respond when clicked, but not as slow as the right clicking in a webpage. Switching tabs is as fast as running FF locally. Reproducible: Always Steps to Reproduce: 1. Setup an XDMCP network 2. Login and get an X session 3. Start FF 4. Load a webpage 5. Right Click 6. *wait*
After some more testing we can say the following: * Running FF2 on the same system is VERY fast, near local performance * Installing a 32 bit Suse also gives some perfomance gains, but not as much as running FF2
I've also tried firefox 3.1beta2 and performace (when right clicking) is as slow as it is in firefox 3. This is with the 32 bit version on an OpenSuse machine.
Depends on: 83395
Attached file XREQUEST trace FF3 —
This is a trace (made with xmon) of what happens when you click the right mouse button until the context menu appears. FF3 does more than 1100 requests...!
Same the effects happens with a SELECT box, i.e. the following code renders EXTREMELY slow as it takes 2 seconds for the select box to appear. <html> <body> <select> <option value="1">value 1</option> <option value="2">value 2</option> <option value="3">value 3</option> <option value="4">value 4</option> <option value="5">value 5</option> </select> </body> </html>
Severity: normal → blocker
Version: unspecified → 3.0 Branch
I can confirm this problem and have include the following as more evidence. No fix yet sorry It is also apparent when using cygwin and other X servers over SSH tunnel Target Linux fedora 10 all updates as of 8 Feb 2009 AMD Athalon Dual Core Host XP Dell 9150 Dimmension Various X servers inc Xwin, CygwinX, Xming Firefox Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 Firefox/3.0.6 I have all FF extension and plugins disabled All firewalls turned off both ends If you start firefox --sync menus speeds up (but still slow) and scrolling goes to slow ! FYI All other progs eg Thunderbird, Seamonkey, Nautilus etc are OK It really looks like slow mouse button events the post above about 1100 requests on click would do it ! Combo box problem also confirmed as true
It might be related to XCB, also see these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=442158 and https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/277069 but I cannot test (or check) this today.
Substituted libX11.so.6 for one from FC7 and the problem is fixed. menus at full speed :-) need to try the recommendation in https://bugzilla.redhat.com/show_bug.cgi?id=442158 ie recompile and try as i suspect the straight swap will break other things ? Will do as soon as time allows...
Update yep break compiz :-( so recompile it will have to be..
Compiz does not matter for us. But it does not seem to be a firefox bug. However the thing I wonder about is why FF2 was fast(er).
Severity: blocker → normal
I am back... Rebuilt libX11-1.1.5-2.fc10 and firefox menus are back to sensible response times. So the question is: a) Is XCB broken or b) Does firefox not support this feature properly
Ooops Should have said Rebuilt libX11-1.1.5-2.fc10 without XCB and firefox menus are back to sensible response times
This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days. Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to RESOLVED, WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: