172053 - Compose window is slow when typing compared to version 1.0

Status: RESOLVED EXPIRED

(MailNews Core :: Composition, defect)

Description

[Edwin Goei]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826

I'm running Mozilla 1.1 on Win2K and the compose window seems *much* slower than
in Mozilla 1.0.  Whenever I type characters, it seems like each character I type
causes lots of CPU time based on the CPU meter.  I am using the plain text
composer and the problem seems worse when I am replying to a long quoted email.
 It seems as if there is too much processing going on during each keystroke.

Reproducible: Always

Steps to Reproduce:
1. Use plain text composer
2. Reply to a quoted message
3. Type text in window

Actual Results:  
When I type rapidly, the cpu meter shows mozilla using lots of CPU.

Expected Results:  
Behave as in 1.0 where it does not use lots of CPU when typing.

Modern theme.  I tried searching for this bug in bugzilla and google, but did
not see anything really relevant.

Comment 1

[Jean-Francois Ducarroz]

-->varada

Comment 2

[Stephan Grossklass]

If my assumption is right, I'm seeing the same problem here (1.2 branch build,
Nov 14, Win32 - just like with many versions b4). It appears it's related to
Mozilla's overall memory consumption (as seen in Windows' Task Manager) - at
~100 MB the speed is still halfway bearable, at ~200 megs, the mail composer
(plaintext here, too) lags like hell. (PIII-500@620, 512 megs, Win2k. Shouldn't
be much swapping here.) Anything else stays as fast as ever. VERY VERY annoying.
(/* Additionally, Mozilla *shouldn't* even come close to 200 megs normally, but
that belongs into another bug. No, my mem cache is just 16 megs, and I usually
have just half a dozen browser windows and one mailnews window open. */)

Comment 3

[Chris Pickett]

yes, i get this problem with 1.2 (nov. 26) as well, it's really painful, i feel
like i'm typing in win 3.1 on a 386 16 mhz (or actually slower).  don't know why
this didn't get fixed for 1.2, it's a pretty big thing.  i'm using w2k. 
previous versions of mozilla (i can't remember, it's been broken for a while)
didn't have this problem.  furthermore, composer doesn't seem to have this
problem so i think it's a mailnews thing only.

Comment 4

[Andy Ozment]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

Windows XP SP1
P4 1.6GHz
640 MB RAM

I can replicate this behaviour in Composer and Browser as well, so I assume it
is with the text engine that underlies all of the Mozilla components.

I have experienced this behaviour since at least Mozilla 1.3. It also seems
likely that these bugs are all the same:
<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=182150">182150</A>
<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=172053">172053</A>
<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=218748">218748</A>
<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=218975">218975</A>

I think that this bug is the most well documented of that four:
<A href="http://bugzilla.mozilla.org/show_bug.cgi?id=218975">218975</A>

Here is how I reproduce the problem:
1. Open a compose window:
  CPU usage: 1%
  Available Mem: 400 MB

2. Start typing in the compose window. I hit keys as fast as I can, repetitively
(not typing words). No matter how fast I type, the text onscreen keeps up with
the speed at which I am typing. However, the CPU usage spikes to 100%. Memory
usage is unchanged.

3. Wait for the CPU usage to return to 1%.

4.a. Start typing again. Now the text appears on the compose window at a _much_
slower rate than before. The text in the compose window lags my typing by a
significant amount.

4.b. Alternatively, move the cursor to the middle of previously written text.
Now if I start typing, the text in the compose window is _really_ slow. It
definitely lags my typing. 

Note that this problem is definitely Mozilla specific. In MS Wordpad or MS Word
I cannot get the CPU usage to rise above 50% and the text onscreen always keeps
up with my typing, no matter how fast I hit keys.

Comment 5

[Peter]

I can reproduce this problem in Thunderbird 0.9 on WinXP as well.  

From experience, I think it has something to do with the linewrapping code. 
Data entry speed slows as a paragraph grows larger, especially in paragraphs
later on in a longish message.  This is also consistent with reports here that
entering text within existing paragraphs is quite slow.

I see that this bug has persisted since *October, 2002* and remains listed as
UNCONFIRMED.  It's user-interface bugs like this one that will discourage
ordinary people from moving to Mozilla.  How do we get this moved up the
priority ladder? 

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.