Closed Bug 16710 Opened 25 years ago Closed 24 years ago

Remote X11/display of mozilla is very slow

Categories

(Core :: Networking, defect, P4)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: roland.mainz, Assigned: pavlov)

References

Details

(Keywords: perf, Whiteboard: [nsbeta3+]) 

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
Severity: critical → major
Target Milestone: M15
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
Keywords: perf
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.
Keywords: beta1
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 (tever@netscape.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-
Whiteboard: [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.
Whiteboard: [PDT-]
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
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 :-) ]
Depends on: 26502
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.
Whiteboard: [PDT-]
Whiteboard: [PDT+]
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.
Whiteboard: [PDT+]
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.
Whiteboard: [PDT+]
setting P1
Priority: P3 → P1
removing pdt+ and beta1.  it seems fast enough now.  let me know if you
disagree.
Keywords: beta1
Whiteboard: [PDT+]
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.
Target Milestone: M14 → M16
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.
nsbeta3
Keywords: nsbeta3
nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: M21 → M18
P4
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
Closed: 24 years ago
Resolution: --- → FIXED
marking verified.
Status: RESOLVED → VERIFIED
Blocks: 83395
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.