Remote X11/display of mozilla is very slow

VERIFIED FIXED in M18

Status

()

Core
Networking
P4
major
VERIFIED FIXED
19 years ago
4 years ago

People

(Reporter: Roland Mainz, Assigned: Stuart Parmenter)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+])

(Reporter)

Description

19 years ago
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

Updated

19 years ago
Assignee: don → pavlov
Summary: M10: Slow rendering with 10baseT-based remote X11-Terminal → [perf]M10: Slow rendering with 10baseT-based remote X11-Terminal

Updated

19 years ago
Severity: critical → major

Updated

19 years ago
Target Milestone: M15

Comment 1

19 years ago
p3 for m15

Updated

19 years ago
Summary: [perf]M10: Slow rendering with 10baseT-based remote X11-Terminal → [perf] Remote X11/display of mozilla is very slow

Comment 2

19 years ago
Over ISDN, it takes mozilla ~3-5 min. to render any content
for www.mozilla.org, what's going on?

Comment 3

19 years ago
worse with DSL.  I do not get remote content.
(Assignee)

Updated

19 years ago
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

Updated

19 years ago
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

Comment 4

19 years ago
Moving "perf" to keyword field.
(Reporter)

Comment 5

19 years ago
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 !!

Comment 6

19 years ago
Putting on beta1 radar.
Keywords: beta1

Comment 7

19 years ago
tever, when you get a chance can you check remote networking with latest Linux 
build and let us know how it looks..thanks!
(Reporter)

Comment 8

19 years ago
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 ?

Comment 9

19 years ago
mcafee, can you try Solaris?
(Assignee)

Comment 10

19 years ago
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.

Comment 11

19 years ago
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.
(Reporter)

Comment 12

19 years ago
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)...

Comment 13

19 years ago
20% slowdown doesn't seem like a stopper. PDT-
Whiteboard: [PDT-]
(Assignee)

Comment 14

19 years ago
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-]

Comment 15

19 years ago
Putting on PDT- radar for beta1.
Whiteboard: [PDT-]
(Reporter)

Comment 16

19 years ago
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 ?
(Reporter)

Comment 17

19 years ago
thougth --> thought
[Aaahhhgrrr, I think I need some sleep again... Good night :-) ]
(Assignee)

Updated

19 years ago
Depends on: 26502

Comment 18

19 years ago
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

Comment 19

19 years ago
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-.

Comment 20

19 years ago
removing pdt-.  This is dogfood.  I can not use mozilla from a different 
machine.
Whiteboard: [PDT-]

Updated

19 years ago
Whiteboard: [PDT+]

Comment 21

19 years ago
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+]
(Assignee)

Comment 22

19 years ago
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+]

Comment 23

19 years ago
setting P1
Priority: P3 → P1
(Assignee)

Comment 24

19 years ago
removing pdt+ and beta1.  it seems fast enough now.  let me know if you
disagree.
Keywords: beta1
Whiteboard: [PDT+]

Comment 25

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M14 → M16

Comment 26

19 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 27

18 years ago
moving to m18
Target Milestone: M17 → M18

Comment 28

18 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Comment 29

18 years ago
Hey pav, this works for me now.  Do you have more stuff to optimize, or can we 
close this?
(Reporter)

Comment 30

18 years ago
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 ?

Comment 31

18 years ago
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?
(Reporter)

Comment 32

18 years ago
> 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/ ...

Comment 33

18 years ago
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.

Comment 34

18 years ago
Pav, do you still think we need to do this?  We should either nominate for
nsbeta3 or future it.
(Assignee)

Comment 35

18 years ago
nsbeta3
Keywords: nsbeta3

Comment 36

18 years ago
nsbeta3+
Whiteboard: [nsbeta3+]
Target Milestone: M21 → M18

Comment 37

18 years ago
P4
Priority: P1 → P4
(Assignee)

Comment 38

18 years ago
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

Comment 39

18 years ago
marking verified.
Status: RESOLVED → VERIFIED

Updated

17 years ago
Blocks: 83395

Comment 40

17 years ago
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.