Trying to browse with Mozilla5 M10 on Solaris/Linux with a X11-terminal (or remotely X in general) is _very_ slow compared to Mozilla 4.x on a 10baseT line. Using 100baseT is good, but the network is much more loaded than normal. What about a tuning config parameter ? Tested with my own m10 build on Solaris 7 SPARC and with SuSe Linux 6.1
Assignee: don → pavlov
Summary: M10: Slow rendering with 10baseT-based remote X11-Terminal → [perf]M10: Slow rendering with 10baseT-based remote X11-Terminal
p3 for m15
Summary: [perf]M10: Slow rendering with 10baseT-based remote X11-Terminal → [perf] Remote X11/display of mozilla is very slow
Over ISDN, it takes mozilla ~3-5 min. to render any content for www.mozilla.org, what's going on?
worse with DSL. I do not get remote content.
Status: NEW → ASSIGNED
Summary: [perf] Remote X11/display of mozilla is very slow → [PERF] Remote X11/display of mozilla is very slow
Target Milestone: M15 → M14
Component: Browser-General → Networking
QA Contact: leger → tever
Summary: [PERF] Remote X11/display of mozilla is very slow → Remote X11/display of mozilla is very slow
Moving "perf" to keyword field.
Can someone which if the same problem occurs with "xnest" ? Maybe GTK+ wants to have some X server extensions which are not present for remove X... Please post any results here !!
Putting on beta1 radar.
tever, when you get a chance can you check remote networking with latest Linux build and let us know how it looks..thanks!
Someone should check this with SOlaris 2.7/MU4, too because MU4 (=Maintaince Update 4) makes Sun's X server X11R6.4 compillant. What about testing it with LBX, too ?
mcafee, can you try Solaris?
It should be getting a bit better. I've been checking in code to help this. Fixing remote X performance will also greatly help running Mozilla locally so this is very good performance stuff.
OK, ran seamonkey remotely on Red Hat using X11 client. There seems to be a slight (possibly 20%) slowdown compared to 4.x. Checked this on the local network using today's build 2000020110.
Did you (email@example.com) test this with 10base? or 100baseT ? We should test this with 10baseT to find the most traffic-intensive "components" of mozilla and optimize them first. Testing with 100baseT isn't very usefull - except for animations it's nearly as fast as local display (from a users viewpoint - please no flames about AGP shared memory X11 vs. ethernet 100baseT performance)...
20% slowdown doesn't seem like a stopper. PDT-
Testing this internally isn't going to be a test that describes this bug as this we are on a 100baseT network. As previously stated, the things causing this bug need to be fixed in order to make linux fast on a local machine.
Putting on PDT- radar for beta1.
Can someone verify that (on Linux/Solaris) refreshing/drawing in one window causes other windows to wait ? I thougth Mozilla is multi-threaded... maybe we should use at least one thread per window to manage the X traffic... Any comments ?
thougth --> thought [Aaahhhgrrr, I think I need some sleep again... Good night :-) ]
I think we need to fix this ASAP. * This is not just a remote problem, the root cause is the same as for the general slow performance on X. Pav should be spending his time fixing it rather than opening up duplicate bugs just to persuade people that it needs to be fixed. * '20% slower than 4.x' doesn't begin to tell the story, since the measurement is on a 100 baseT network, and 4.x is itself too slow. * Remote performance is abysmal, making it unusable for developers working from home (read McAfee and DougT's sad tales of woe). This gives us an internal need to fix the problem, regardless of whether we care about that market.
No longer depends on: 26502
pavlov has created http://bugzilla.mozilla.org/show_bug.cgi?id=26502 to address Linux performance. If you feel this bug itself should be considered also, please remove pdt-.
removing pdt-. This is dogfood. I can not use mozilla from a different machine.
Did this bug actually get assigned a PDT+? I don't see it from the comments log. Also, I think that the summary may be misleading. It should not be a beta1 requirement to be able to use Seamonkey remotely. On the other hand, if this is a major general linux perf problem, it could be. Removing PDT+ to ensure consideration.
What? If you check the bug activity, a PDT person made this PDT+. Using ANY application remotly is a requirement for Linux. Don't remove flags from my bugs. Other people require this and are blocked from getting work done if this doesn't work.
Priority: P3 → P1
removing pdt+ and beta1. it seems fast enough now. let me know if you disagree.
The same problem appears when running Mozilla remote over a slow RDP/ICA connection (WinNT terminal server). IE isn't bothered by this. I have this feeling Mozilla renders the page as one big image, while IE renders it as a collection of multiple text area's.
Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2
Target Milestone: M16 → M17
moving to m18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Hey pav, this works for me now. Do you have more stuff to optimize, or can we close this?
To quote Wouter Coene: > IE isn't bothered by this. I have this > feeling Mozilla renders the page as one big image, while IE renders it as a > collection of multiple text area's. Is this still true ? If yes it would be an optimisation - incremental rendering. Another optimisation would be to avoid that animated GIFs/anims may eat up all network bandwith - making mozilla very sluggish. Or should I file a seperate bug for this ?
Roland.Mainz@informatik.med.uni-giessen.de: > Is this still true ? If yes it would be an optimisation - incremental > rendering. Tried both M16 as well as the latest daily build (buid id 2000071108). M16 is *very* slow over a Citrix ICA connection (@ 46K; IE is doable over such speeds). The daily is an improvement, but not quite 'it'. It's still nowhere near IE's speed though. Should I test it with Netscape 4.x as well?
> Should I test it with Netscape 4.x as well? If you have the time - yes, please. And it would be also nice to test the behaviour on pages with heavy (GIF-)anims like http://www.fishydance.com/ ...
Running on a not so fast machine, you can see that mozilla drawing a window not only blocks other mozilla windows, but all other windows as well. One could consider this a problem of X, one could also say that one client shouldn't hog it so other clients can't get through. I don't know how mozilla draws the content area, but if it is painted internally and then sent to the X server as one big image I can understand why it blocks.
Pav, do you still think we need to do this? We should either nominate for nsbeta3 or future it.
Target Milestone: M21 → M18
Priority: P1 → P4
About us drawing in blocks... this is probably double buffering. We should make this a pref I suppose, since I believe that running without double buffering remotely would be a lot faster (I'll file a bug on this tomorrow). http://www.fishydance.com/ currently crashes mozilla (bug 49432), but that site is just silly and I don't really care if it works or not (double buffering could effect this too). I am satisfied with the performance running remotly with ssh over ADSL. 10mbit and 100mbit is useable. I feel that this bug has served its purpose though, and that using mozilla remotly is useable. While not as fast as it should be, I think that it is good enough. If you can find specific areas that are slow when running remotly, please file new bugs on these.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
I don't think this was a "networking" problem, shouldn't it have lived in something to do with rendering? (I'm going out of my way to set the record straight so I don't have to field XWindows performance issues in the future...)
You need to log in before you can comment on or make changes to this bug.