136230 - All redraws are EXTREMELY slow

Status: RESOLVED DUPLICATE of bug 84920

(SeaMonkey :: General, defect)

Description

[Tilo Sloboda]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031103

All redraws are extremely slow - it's quite annoying - makes 
Mozilla almost unusable.

Opening windows, re-drawing parts of windows.. all are very very slow. ...
compared to Netscape 4.76 that is. 

This is also very noticable when new email arrives (time between the 
beep and when the message actually shows up),  and when selecting a message
(time between clicking on the message and delay until it actually shows up)


Reproducible: Always
Steps to Reproduce:
1. open mail window
2. create other window and cover the mail window with it
3. bring mail window to top and watch slow redraw. 



Actual Results:  I had to wait for a few seconds..  (too long)
  ... and was contemplating if Mozilla is mature enough for every day use. 


Expected Results:  redraws as fast as Netscape 4.76

doing a "stings mozilla-bin", i found two interesting values: 
    --gdk-no-debug  and  --gtk-no-debug

Is it possible that the 2002031103 build has some extra debugging
switched on for the GUI?   
If so, is there an optimized build available, or is there a way 
to speed things up? 




ts134341@tilo% strings mozilla-bin | grep debug
%s--gdk-debug=FLAGS%sGdk debugging flags to set
%s--gdk-no-debug=FLAGS%sGdk debugging flags to unset
%s--gtk-debug=FLAGS%sGtk+ debugging flags to set
%s--gtk-no-debug=FLAGS%sGtk+ debugging flags to unset

Comment 1

[Roland Mainz]

1. I can confirm that refreshing the content is extremely slow even in non-debug
builds
2. Just guessing - do you use a gcc build (gcc builds are twice as slow as Sun
Workship builds - and even these could be much better if we would use higher
compiler optimisation levels...) ?

BTW: Which kind of machine do you have (what does % uname -a # say ?) ?

Comment 2

[Tilo Sloboda]

The redraw for the email is just toooo slow to be usable. 

Changing to a different mail folder (IMAP) and waiting for the new email 
to show up takes *forever* -- this is not usable for a commercial environment.

I get tons of email and need to see *quickly* what's new and navigate quickly
between messages/folders.


Hmm.. is somebody working on the speed issues?   I think it's really crucial!
or otherwise it's not usable :-(   hence the change to "major"



I'm not sure which CC the Solaris 2.8 bits were built on -- i picked up the
pre-compiled bits for Solaris from mozilla.org



Machine type and memory size (sorry for not including it in the first place):


ts134341@tilo% uname -a
SunOS tilo 5.8 Generic_111433-02 sun4u sparc SUNW,Ultra-5_10

WOW - that Mozilla executable is FAT!!!


load averages:  0.33,  0.27,  0.18                                             
 15:01:11
62 processes:  60 sleeping, 1 running, 1 on cpu
CPU states: 94.4% idle,  5.6% user,  0.0% kernel,  0.0% iowait,  0.0% swap
Memory: 256M real, 62M free, 512M swap free

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  473 ts134341   9  23    0   60M   51M sleep   1:29  6.57% mozilla-bin
  301 root       1  34    0  150M   53M sleep   0:39  5.67% Xsun
  599 ts134341   1  24    0   25M   17M sleep   0:03  1.14% netscape.en-us
  614 ts134341   1  34    0 1424K 1240K cpu     0:00  0.51% top

Comment 3

[Roland Mainz]

Reporter:
Can you please do two things:
1. Update your system with the latest recommended patch cluster
2. Get a patch for your m64 driver (the gfx driver for your onboard PGX64 card)

Both things should help a little bit...

----

Do not trust the output of "top" - it always shows the adress space usage 
(which includes mmap()'ed files and shared memory) and not the real memory
usage....

Comment 4

[Matthias Versen [:Matti]]

to Roland : I can't fix this bug and i dunno where it should go...

Comment 5

[Roland Mainz]

Matthias Versen wrote:
> to Roland : I can't fix this bug and i dunno where it should go...

I know that.
The real fix for performace issues on Solaris is the same fix as used on Linux -
use "-O2" (gcc - see bug 53486 ("Default linux MOZ_OPTIMIZE_FLAG is -0 !!")) -
or -xO4 if you use Sun Workshop 6 Update 2.

Comment 6

[Mark Pulver]

(also posted this info to #57451)

I have more timing numbers for this problem...

Reference this page (warning, it's a big flame fest):

http://www.the-gas-station.com/messages.cfm?type=messages&thread_id=47624

With a T3 line for bandwidth, Mozilla v1.1b (on Windows) will take 72 seconds to
load and render the page. IE will show it in about 10 seconds. The large spread
in time can also be seen when loading the page locally.

Looking at the source of the page, it looks like the issue may come from the
amount of formatting. There are a large number of table objects on that page.

Comment 7

[Jay Smith]

I am _begging_ to get this fixed for the 1.3 version.  If it is not fixed my
company will have to continue using Netscape 4.76 on Red Hat 6.x for mail. Can
you believe it?  We are in the midst of migrating to Red Hat 8 and have really
hit a wall on this.

I believe that this bug may be the same or is very closely related to:

  Bug 84920
  Bug 89919 ?? maybe
  Bug 104176
  Bug 103241 
  Bug 136230
  Bug 163264

I am reporting the same message to these other bug nubmers.

This bug is extremely serious to those users that it affects and makes Mozilla
-- ESPECIALLY THE MAIL which does constant opening and closing of windows --
unusuable in a business/production environment.  Several reporters have stated
this, but so far -- after more than 18 months -- to no effect.

I believe that this bug has not received the proper attention because:

1) It was spread over many reports that used varying terminology. 

2) It was assigned to various people, one of whom appears to have been oblivious
about it before he become employed elsewhere. Nobody seems to have realized that
all these reports are about the same thing.

3) ***** The bug is less noticable on faster or dedicated systems that
developers and engineers are more likely to use. However, for a business user
working over a busy network, connecting to a busy server, it is a PRODUCTIVITY
KILLER.

The distillation of all the reports is:

PROBLEM:

A) Any screen redrawing resulting from window opening, closing, moving,
minimizing/maximizing, or resizing is EXTREMELY SLOW, particularly when multiple
Mozilla windows are open.  Redrawing is also very slow when focus is changed
from one mail folder to another or when the user right clicks on a mail folder
to get a context menu.

For example, when I move THIS browser window, I momentarily see FIVE (5)
duplicates of this window and I can count four seconds before all the screen
redrawing is done.  Resizing is even slower -- it take about an 8-count before
the screen is redrawn.  Closing this window also takes about an 8-count before
the screen is fully redrawn. Minimizing this window is quite bizzare; there are
about fifteen (15) momentary black-outlined rectangles getting smaller and
smaller as it minimizes; a 5-count before all redrawing is complete.

B) If you are working only in one screen typing like I am now, this is not a big
deal. However, _MAIL_ users are constantly opening message windows, changing
focus between IMAP folders, etc., etc.  As I have spent a couple days test using
the mail, I have made many mistakes because I thought all the redrawing was done
when it was not. As a result, messages have been dragged to the wrong folders,
folders have been expanded or unexpanded when I was trying to do the opposite,
etc.  (I have tons of experience using NS 4.76 doing the exact same work and
have never had any of these kinds of problems.)  This is a PRODUCTIVITY KILLER
for mail users.

C) Reporters have reported this on:
Linux X11
Linux (ver not stated) on a PC
Windows 95 PC
Windows NT4 PC
Windows NT 5.1
Windows 2000
OS X on iMac & G4 (but maybe only 10.2 or higher??)
Sun OS (version ?)
Solaris 2.8

D) All reporters seem to be reporting on reasonably (to very) fast machines with
decent to excellent amounts of RAM.

E) Several reporters have clearly stated that it is "virtually unusable" or
otherwise not useable in a business environment.  I must agree!

MY EXPERIENCE:

1) This Mozilla is running on a Red Hat 8 server to which we are migrating. Our
migration is essentially stalled until this issue is addressed.  I cannot
believe that I am going to have to keep running a Red Hat 6.x server to provide
Netscape 4.76 email to my staff!

  Red Hat 8.0 with kernel 2.4.18-18.8.0 and all but the latest (i.e. last two
weeks) updates via RH up2date. UW IMAP vers 2001a release 15 from Red Hat 
supplied RPMs (from RH install CD). 

  Mozilla 1.2.1 (Xft build) from Mozilla RPMs
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

2) When we first saw the problem, we assumed that it was an X problem, so we
tested per the below.  The workstations are Windows 95 PCs (we hope to be
Microsoft free by the end of 2003!) running X windowing software to provide X
access to the Linux servers.

*** NOTE THAT THIS X WINDOWING (and 10 mb network in general) IS PROBABLY
PROVIDING SOME OF THE DELAY THAT MAKES THIS BUG MORE OBVIOUS.  (It is sort of
like testing an application over a 28.8 kb modem to see what is really going
on.) HOWEVER, _ALL_, I REPEAT _ALL_ OF OUR OTHER RH 6.X AND RH 8 APPLICATIONS DO
_NOT_ HAVE ANY OF THESE REDRAW SPEED ISSUES, EVEN WHEN THE NETWORK IS UNDER
HEAVY LOAD.

a) Tested through SCO's PC XVISION 7.32 running on Windows 95 running Mozilla
running on our RH 8 server.  Mozilla is the only application that shows any
redraw speed problems.  This is our oldest Xwindowing software.  The PCs tested
were 300 to 400 MHZ machines with 256 to 512 MB of RAM.

b) Tested through CYGWIN XFREE86 4.2 (the latest production release) running on
Windows 95 running Mozilla running on our RH 8 server. Mozilla is the only
application that shows any redraw speed problems.  On this newer Xwindowing
software, the redraw problem was perhaps 20% less (20% faster) than on the
XVISION. The PC tested with Cygwin (specifically installed for THIS test) is a
400 MHZ machine with 512 MB of RAM.

c) Tested directly on our Red Hat 8 server console (i.e. no network, PC, or
windowing software to slow things down) running DUAL 1 GB processors with 3
(three) _GB_ of RAM.  Redraw is noticable, but would not bother anybody. When
moving one Mozilla browswer window around on top of another, I get momentary
duplication of the chrome -- about five to six copies of the window. By
comparison, similar window movements of other application windows on this
machine do NOT show this delay -- for other applications, redraw is
instantaneous. However, as I said, it is perfectly usable -- BUT not every staff
member (none, in fact) can use the server as a workstation!

Please help!

Jay

Comment 8

[Andrew Hagen]

Dupe.

*** This bug has been marked as a duplicate of 84920 ***