Closed Bug 141900 Opened 22 years ago Closed 22 years ago

Text entry fields in forms excruciatingly slow.

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: shannyk, Assigned: kinmoz)

References

Details

(Keywords: perf, Whiteboard: [adt2 RTM] [FIXED_ON_TRUNK] [ETA 07/22])

Attachments

(4 files, 2 obsolete files)

Make sure nsIClipViews stay clipped
1.37 KB, patch
kmcclusk
: review+
waterson
: superreview+
Details | Diff | Splinter Review
Patch for nsBlockFrame.cpp and nsBox.cpp
2.00 KB, patch
dbaron
: review+
waterson
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
3rd pass for async reflow, painting, and scrolling
40.46 KB, patch
mozeditor
: review+
waterson
: superreview+
chofmann
: approval+
Details | Diff | Splinter Review
One line patch to disable attachment 87307 (with comments)
877 bytes, patch
Brade
: review+
sfraser_bugs
: superreview+
brendan
: approval+
Details | Diff | Splinter Review 
In text entry fields on forms and in the navigation bar at the top, the letters
appear far slower than they're typed, which is extremely irritating as I haven
on idea what I'm typing or how I'm spelling it, and I have to wait for it to
catch up with me.  And I only type maybe 50 wpm.
Which build are you using?  This was vastly improved in the last two weeks...
Mail from reporter says that the build is RC1 (Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc1) Gecko/20020417).

This should have the fix for bug 135146 already in it.... jesup?  can you
reproduce this?
Keywords: perf
What speed machine, memory, etc?

Example URL's?
Using RC1 on a Win95 P233MMX 64MB, I have no problems with typing speed in the
URLbar (a little slow but that's the autocomplete stuff) or in bugzilla text
fields of various types.

We need more info and more testers.  URL's, OS, CPU, mem, gfx card, more details
about what "slow" is.  Video mode/depth.  Did this happen in 0.9.9?  Does this
happen now on trunk?
From: Variant

>What speed machine, memory, etc?

K6-II 450, I know it's slow, but it's never had problems with anything else
like this before, 184 megs of RAM, decent amount of hard drive space...
It's slightly better when I set my keyboard back to QWERTY, as I type in
Dvorak but share the computer, so I have to change it in Windows rather
than using my hardwired board.

>Example URL's?

Any with a text entry field, the bugzilla form is a perfect example.

IMHO the priority on this should be set to 'major'.  It's obviously confirmed on
many OS and hardware platforms and affects all text field input, which affects a
large bulk of all web applications such as groupware and email.

I wish I could give more contextual info as to why this happens.  I have always
seen it in the many months I've been using Mozilla from 0.9.4 up to the current
RC1.  Always on MacOS10 from 10.0.4 up to the current 10.1.4.  Always on my
Pismo Powerbook, 400 MHz G3, 192 MB RAM.  It's not due to swapping or to any
system activity outside of Mozilla.  'top' shows zero cpu usage from any other
process, I know nothing else is happening with the system, and usually only
5-20% cpu usage by Mozilla at the time of slowdown.  Mozilla does not ever tend
to consume absurd amounts of cpu time and only goes above 20% during heavy
animations and such.

I have watched this behavior intently, because I use Yahoo Mail 24/7 and I often
resort to typing my emails in TextEdit and pasting them into Yahoo Mail's
'compose' form.  Yet I can find no distinct pattern to the slowdown.

All I know is that right now it's going almost tolerably fast here in this
buzilla form, and I can slightly outtype it and see a visual sluggishness.  It
takes Mozilla 15 seconds to type 100 characters.  At the same time, right now, I
can switch to Yahoo Mail with no animations happening and it takes 25 seconds to
type 100 characters.  I'm interactively typing "This is a test." six times in
each case.

At the same time as all this, pasting from the clipboard is virtually instantaneous.

I'm pretty sure that if I quit and restart Mozilla, speed is restored.  I can
check that.

Obviously it's not OS- or hardware-related, as is evidenced by the other posters
here.  It's almost like it just wants to be slow ;-)

The upside is that when this is fixed, I'll feel like a million bucks  ;> 
Congratulations on all the Mozilla contributors; this project is like a miracle.
FWIW, I have seen it slow down to literally one character per second.
Based on reports, confirming.  It sounds like it's an issue with the exact size
and/or position and/or place in the DOM tree that the text widget is.  We've had
problems with text-widget-refresh before due to excessive dirtying in Reflow;
this may be another case of it.  Sounds like we're spending time in Reflow().

People who've seen this (shanny, dan): please try one of the reflow-rewrite
experimental builds (see bug 129115).  That changes/improves a number of issues
surrounding how reflow occurs and may fix this.

Reassigning to layout; ccing some layout and editor people.
Assignee: Matti → attinasi
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: imajes-qa → petersen
Somebody please point me to a place where I can reproduce this problem. I have
no problem on bugzilla or any other form that I've tried using in the past
month. (I.e., in a build that includes the fix for bug 135146 -- post 2002-04-12
or so.) Marking WFM to inspire reporters to come up with concrete examples.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Wow, marking this as resolved and stating that we haven't provided concrete
examples is a total mistake.  :)  Read any of the entries here; we all say that
the bug appears in absolutely every text field on every site, using a wide
variety of OS and hardware configurations, and another states a theory on
exactly where the problem lies.  The problem is well confirmed and I'll try one
of the suggested alternate Mozilla builds asap.  I suggest that someone change
the status and resolution to something appropriate, and set the severity to
'high'.  Thanks!
Does it appear on the text field on *this* page, using a current build?
Yep.  The bug appears on every single text field on every single page, including
this one.  My Mozilla version is RC1 {Build ID: 2002041712}.  Thanks!
Is comment 6 saying that it *becomes* slow after using Mozilla for a long time?
 How long?  And doing what?  Is there some action you can repeat a number of
times to get the problem to start happening, without doing anything else?
Is this fixed with a new profile ?
(run "mozilla -profilemanager" to create an additional test profile)

I apologize, but I partially misunderstood <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=141900#c9">comment 9</a>.  I'm
going to start testing with the build of the day, rather than just with RC1. 
I'll post additional concrete examples in the next few days, if they still
exist.  I'm new at the Mozilla QA process, so I assume <a
href="http://ftp34.newaol.com/pub/mozilla/nightly/latest/">this</a> is the
correct distribution to test with.  Thanks!
Using build 2002051608, it's *still* every bit as slow with the text entry, I'm
typing this and unable to see what I'm typing as I type it, so have to go back
once it's finished and correct mistakes.  Might as well go make a cup of tea
while I'm waiting.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
OK. We have half a dozen bugs on this.  Marking them all depending on this one,
since this one has all the relevant people cced.

There seem to be 3 distinct classes of problems:

1)  Something about page backgrounds
2)  Slow typing in textareas that have lots of text already
3)  Just slow for no reason....

Someone who knows this code should sort these bugs out and figure out which, if
any, are dups of what.
Blocks: 110325, 119318, 128557, 128658, 129857, 145194
If you turn on paint flashing and type in textwidgets, you will see that when we
have enough text that does not fit within the viewable region of the textwidget,
that we are invalidating way too much. The invalidated area includes areas
outside the textwidget, presumeably the entire size of the view being scrolled
inside the textwidget. I'm not exactly sure why this isn't being clipped to the
scrollport's clipped view bounds.

Put a breakpoint in nsViewManager::UpdateView() and you'll see that these large
invalidations are the result of calls to nsViewManager::ResizeView().

In any case this impacts the speed of typing because we are invalidating and
repainting the entire size of the scrolled view for each keystroke. This was
also slower when the invalidated region interstected the part of a page that had
a background image with an alpha channel, because compositing was *real* slow,
but I think dcone re-enabled an optimization that fixed that problem.

Using the test case in bug 128568 attachment 72256 [details]:

  http://bugzilla.mozilla.org/attachment.cgi?id=72256&action=view

and filling it with a lot of text so that I had vertical and horizontal
scrollbars, I was able to verify the 2 things that are bogging us down:

1. Over invalidating. As I stated in my previous comment, calls to ResizeView()
   are causing the entire scrolled view to be invalidated. It's not getting
   clipped by it's ScrollPortView parent because the ScrollPortView never gets
   the NS_VIEW_FLAG_CLIPCHILDREN bit in it's mVFlags set.

   Apparently the view manager manages the setting/unsetting of this bit
   on views, so I hacked nsScrollPortView to inherit from nsIClipView,
   and implemented nsScrollPortView::SetViewFlags() to prevent anything
   from turning the NS_VIEW_FLAG_CLIPCHILDREN bit off and it improved
   typing, I'd say by at least 50% in attachment 72256 [details].

   The reason I had to implement SetViewFlags() was because
   nsContainerFrame::SyncFrameViewAfterReflow() calls the view manager's
   SetViewChildClipRegion() with a null region which unsets the
   NS_VIEW_FLAG_CLIPCHILDREN on the nsScrollPortView.

2. The editor forces synchronous reflows and paints when it's done batching
   all of the operations necessary to perform the edit task.

   Once again I hacked nsEditor::EndUpdateViewBatch() to call

      presShell->EndReflowBatching(PR_FALSE); // Don't call FlushPendingEvents()
      mViewManager->EndUpdateViewBatch(NS_VMREFRESH_NO_SYNC);

   I then hacked EndReflowBatching() so that it called PostReflowEvent() if
   it wasn't going to call FlushPendingEvents().

   This got rid of the rest of the lag between typing and showing up on screen,
   though the text that was typed started showing up in chunks, instead of a
   single char at a time in sync with my fingers. This also might look funny
   on Linux, because I seem to remember that gtk prevents processing of
   repaints until things are all idle.

   Doing all this breaks selection-auto-scrolling, which keeps the views in
   sync with where the caret is as you type. We need to figure out how to delay
   the scrolling necessary until after the reflow and painting have happened.

Comments?

   
CC-ing roc since kin talks about views and roc knows a lot about them and can
maybe  tell us why it is the way it is.
Part 1 of kin's comment breaks down into two overlapping issues.

Ideally ResizeView() should not have to invalidate anything because reflow
should be invalidating whatever changed and caused the view to be resized. But
layout currently doesn't do that so we have this hack. This ought to be fixed
sooner or later.

The other issue is that nsScrollPortFrame's NS_VIEW_FLAG_CLIPCHILDREN flag is
being cleared by SetViewChildClipRegion. That is definitely wrong. The question
is what should happen here, if CSS clipping is applied to a scrolling frame.
It's probably specified in the legendary Lost CSS2 Errata. My guess is that the
clip area for an nsIClipView (i.e., a scrolling view) should always be the
intersection of the CSS specified clip area and the view's bounds. I'll attach a
patch to achieve this.
Untested, but should be very low risk. Give it a spin.
Taking off attinasi's plate.
Assignee: attinasi → kin
Status: REOPENED → NEW
Priority: -- → P2
Target Milestone: --- → mozilla1.0
I tested the patch and it works. Let's get it r/sred by kmcclusk and waterson.
I did a profile of banging on my keyboard for 60 seconds into the
textarea on a bugzilla bug.  On my P-233 running RedHat 6.0 (with my
optimized build compiled with egcs 1.1.2), this pegs the CPU.

Out of 5006 hits total, where each of the following bullets excludes all
of the things above it:
 + 247 hits (4.9%) within nsCaret::DrawCaret, of which:
                 76 nsDeviceContextGTK::CreateRenderingContext(nsIView *, ...)
                 51 nsTextFrame::GetPointFromOffset(nsIPresContext *, ...)
                 22 nsCaret::SetupDrawingFrameAndOffset(void)
                 21 nsCaret::GetViewForRendering(nsIFrame *, ...)
                 20 nsRenderingContextGTK::InvertRect(nsRect &)
                 11 nsCOMPtr_base::assign_with_AddRef(nsISupports *)
                 10 nsCaret::MustDrawCaret(void)
                 10 nsRenderingContextGTK::PopState(int &)
                  5 nsRenderingContextGTK::PushState(void)
 + 672 hits (13.4%) within nsCaret::SetCaretVisible, almost all of which
   is in the locking done by adding and removing timers
 + 976 hits (19.5%) doing painting (within nsViewManager::Refresh)
 + 536 hits (10.7%) within reflow, of which:
   + 202 was within nsTextFrame::Reflow, of which:
         99 nsTextFrame::MeasureText(nsIPresContext *, ...)
         81 nsFrame::Invalidate(nsIPresContext *, ...)
          6 DeviceContextImpl::GetMetricsFor(nsFont &, ...)
          2 nsXPLookAndFeel::GetColor(nsILookAndFeel::nsColorID, ...)
 + 570 hits (11.3%) within the XPending call in the handle_gdk_event
 + 423 hits (8.4%) in poll (the time I wasn't keeping up with Mozilla,
   since I did pause in the middle to let it catch up)
 + 425 hits (8.5%) within nsXBLWindowKeyHandler::WalkHandlers (lots of time
   within QueryInterface here that wouldn't be present with a late
   gcc-2.96-RH or a gcc 3.x due to the GetIID optimization)
 + 43 hits (0.9%) within nsPlaintextEditor::CanPaste, all doing
   nsClipboard::GetTargets
 + 299 hits (6.0%) within nsPlaintextEditor::InsertText, of which
   87 are within nsTypedSelection::Collapse and 133 hits are within
   nsEditor::Do.
 + 806 hits (16.1%) are doing other things, among them a bunch of
   HandleDOMEvent stuff (and stuff that it calls)

I have separate jprof profiles for all of the segments above.
Blocks: 143206
Comment on attachment 84190 [details] [diff] [review]
Make sure nsIClipViews stay clipped

sr=waterson
Attachment #84190 - Flags: superreview+
Comment on attachment 84190 [details] [diff] [review]
Make sure nsIClipViews stay clipped

r=kmcclusk@netscape.com
Attachment #84190 - Flags: review+
Blocks: 143873
Status: NEW → ASSIGNED
kin, before I check this in, could you apply the patch and verify that it
addresses your point #1?
I'll try out the patch and report back.
So roc's patch causes all invalidations, triggered by typing into a text widget,
to be clipped to the widget bounds, so now things invalidate like they did when
I had my quick hack in my tree ... but we are still invalidating the entire
bounds of the widget for each char typed.

I'll give a thumbs up on this patch since it gives a noticeable perf boost while
typing in some of the testcases in the various bugs that depend on this one.

The 2 issues left to resolve are:

1. Get rid of the ResizeView() hack.

2. Modify the editor to use a scheme (PL_Event perhaps) that will reduce the
number of synchronous reflow->paint->scroll calls so that some of the edit
operation cleanups get batched together.

Fixing item 2 above will give us the biggest boost ... at least that's what the
EndUpdateViewBatch() hack I have in my tree seems to suggest.
OK, I'll go ahead and check my patch into the trunk.
OK, I checked the patch into the trunk.
Here's my first pass attempt at making text widgets use async reflow, painting
and scrolling full time.

If someone could kindly apply the patch and check it out (especially on linux)
and give some feedback as to what they think of the speed gain and the way the
text shows up as you type a flood of characters, it would be much appreciated.

This patch in conjunction with roc's patch speeds up text entry tremendously on
most of the test cases that depend on this bug.

We still have some problems with:

http://www.wikipedia.com/wiki/September_11,_2001_Terrorist_Attack/New_York_Times_stories&action=edit


when typing a flood of chars at the bottom of the textarea. I think the delay
in chars showing up is actually due to reflowing, though I haven't verified
that.

Most of the patch is modifying the various ScrollSelectionIntoView() methods to
use the extra aIsSynchronous arg.
Comment on attachment 85841 [details] [diff] [review]
1st pass attempt at making text widgets use async reflow, painting and scrolling.

Also, regarding this patch, I am aware of the need for a generic
ScrollSelectionIntoView() utility method in the editor. I just wanted to get
this patch out there for the weekend.
Once we fix the ResizeView problem (and any associated incremental reflow
issues) we should get a major speed boost --- there is simply no good reason for
us to repaint the entire widget every time the user inserts a character. We
don't need to think about making tradeoffs in the user's experience until we've
exhausted those possibilities.
I think we need a patch like kin's.  See the profile notes in comment 25 --
that's a very broad profile of a situation where we peg the CPU.
So apparently I didn't include nsIFrameSelection.h when I generated this patch.
(Thanks to brade for pointing that out.) I'll post a new one shortly with some
minor changes that actually builds.

I showed waterson the delay I mentioned above with the www.wikipedia.com page
... the printf()/fflush() calls I added show that we are indeed in a reflow at the
time of the delay.

waterson asked me to apply my patch to the branch to see if any of his reflow
tree changes may have impacted this ... the answer is no. The branch suffers the
same delay.
Blocks: 149580
This version of the patch fixes the typing delay problem with the wikipedia
test case and significantly boosts scrolling performance of the textarea too.

Apparently attribute changes on the scrollbars, and dragging the slider frame
around with the mouse causes the box code to push dirty bits all the way out of
the text control frame up to it's parent (form or enclosing block). In the case
of the wikipedia test case, this meant that we were reflowing the enclosing
table every time we did anything with the scrollbars.

I still need to modify the patch so that the editor uses a single method to
check the appropriate editor flags, and pass the correct sync value to
ScrollSelectionIntoView().
Attachment #85841 - Attachment is obsolete: true
All/All per Comment #6.
OS: Windows 98 → All
Hardware: PC → All
I've posted a document at http://students.luther.edu/~andersma/Webmail.html that
I think illustrates either this problem or one of the related ones.  I'm not
sure which one, exactly, as I don't have time to test the code in detail right now.
Mark, the changes in this bug allow realtime typing on that page. I used the
students.luther.edu page when first annalyzing the problems. It's one of the
cases where we were invalidating too much outside of the text widget causing the
compositor to kick in and re-composite all of the images with alpha channels in
the sidebar of that page.
Wonderful!  I look forward to the patch landing, so my choice of default 
browser can change permanently. :)

(If you want to toss me an email to this question to avoid cluttering the 
bug....  "I used the students.luther.edu page when first annalyzing the 
problems."  You mean you actually used it back at the beginning, before the 
patch?  Did I comment on a bug a while back that I don't remember, or did you 
randomly find Luther's Webmail?  Or am I reading too much into this? :) )
I'm going to be breaking up the async reflow, painting and scrolling patch into
2 diffs so I can get reviews and check in the smaller one:

The 1st diff will be for nsBlockFrame.cpp and nsBox.cpp, not related to the
editor async changes, which gives a noticeable improvement in scrollbar response
and typing in most of the testcases.

The 2nd diff will be changes needed to get async reflow, painting and scrolling
working properly in the editor..


This prevents the propogation of reflow commands up the parent hierarchy in 2
cases:

  1. When a reflow root is encountered in the box world.
  2. When a block frame has more than one dirty child.

This gives us noticeable performance improvement when typing and scrolling
textareas with large amounts of text, especially when the textarea is inside a
complex table, like in the wikipedia test case.

dbaron can I get an r=, waterson can I get an sr= on this one?
This is almost the same as the 2nd pass patch with the following:

  1. Removed redundant ScrollSelectionIntoView() calls in
nsEditorEventListeners.cpp.

  2. Combined the eEditorDisableForcedUpdatesMask, and
EditorDisableForcedReflowsMask flags into one flag (eEditorUseAsyncUpdatesMask)
since one will never be used without the other.

  3. Added hacks to keep (I hope) IME caret code working since it expects the
frame and content trees to always be in sync.
Attachment #86738 - Attachment is obsolete: true
Comment on attachment 87306 [details] [diff] [review]
Patch for nsBlockFrame.cpp and nsBox.cpp

r=dbaron
Attachment #87306 - Flags: review+
Comment on attachment 87307 [details] [diff] [review]
3rd pass for async reflow, painting, and scrolling

r=jfrancis.  The only thing that I'm a bit concerned about is are the IME
changes.  They should work fine, but they rely on the view update batching
having not been entered prior to setting the state to sync.  If the view update
batching has already begun, further nested batches with different sync/async
state are immaterial.

It is unlikely that the code would ever change in such a way as to cause this,
though.
Attachment #87307 - Flags: review+
I was worried about that too, but I did a sweep through all of the editor code
that called the IME routines I modified, and they are all called or triggered
directly from an editor IME event handler method that doesn't open a view update
batch, so I think we should be ok.

Comment on attachment 87306 [details] [diff] [review]
Patch for nsBlockFrame.cpp and nsBox.cpp

sr=waterson
Attachment #87306 - Flags: superreview+
Comment on attachment 87307 [details] [diff] [review]
3rd pass for async reflow, painting, and scrolling

sr=waterson
Attachment #87307 - Flags: superreview+
Comment on attachment 87306 [details] [diff] [review]
Patch for nsBlockFrame.cpp and nsBox.cpp

Patch for nsBlockFrame.cpp and nsBox.cpp checked into the TRUNK:

  mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.516
  mozilla/xul/base/src/nsBox.cpp		 revision 1.55
Comment on attachment 87307 [details] [diff] [review]
3rd pass for async reflow, painting, and scrolling

3rd pass for async reflow, painting, and scrolling (with comment request from
waterson) checked into TRUNK:

  mozilla/content/base/public/nsISelectionController.idl      revision 3.15
  mozilla/content/base/src/nsSelection.cpp		      revision 3.123
  mozilla/editor/composer/src/nsEditorShell.cpp 	      revision 1.315
  mozilla/editor/idl/nsIPlaintextEditor.idl		      revision 1.9
  mozilla/editor/libeditor/base/nsEditor.cpp		      revision 1.367
  mozilla/editor/libeditor/base/nsEditor.h		      revision 1.144
  mozilla/editor/libeditor/html/nsHTMLDataTransfer.cpp	      revision 1.51
  mozilla/editor/libeditor/html/nsHTMLEditor.cpp	      revision 1.424
  mozilla/editor/libeditor/text/nsEditorEventListeners.cpp    revision 1.200
  mozilla/editor/libeditor/text/nsPlaintextDataTransfer.cpp   revision 1.21
  mozilla/editor/libeditor/text/nsPlaintextEditor.cpp	      revision 1.41
  mozilla/editor/txtsvc/src/nsTextServicesDocument.cpp	      revision 1.41
  mozilla/editor/ui/dialogs/content/EdTableProps.js	      revision 1.66
  mozilla/embedding/components/find/src/nsWebBrowserFind.cpp  revision 1.15
  mozilla/extensions/xmlterm/base/mozXMLTermSession.cpp       revision 1.49
  mozilla/layout/base/public/nsIFrameSelection.h	      revision 1.50
  mozilla/layout/html/base/src/nsPresShell.cpp		      revision 3.548
  mozilla/layout/html/forms/src/nsGfxTextControlFrame2.cpp    revision 1.206
  mozilla/mailnews/compose/src/nsMsgCompose.cpp 	      revision 1.347
  mozilla/xpfe/browser/resources/content/viewPartialSource.js revision 1.2
Filed bug 151682 to address last remaining issue --> ResizeView() hack over
invalidates while typing in a text widget.

If no one has any objections, I'm going to start dup'ing all of the bugs that
depend on this one since this bug has patches that address all of the major
problems:

  1. Typing causes areas outside of the text widget to be invalidated.
  2. Typing causes reflows to leak outside of the text widget.
  3. Typing forces synchronous reflows and paints for each character typed.

The performance degredation in each of the testcases/urls in the dependent bugs
are due to one of these reasons, or a combination of these reasons.
FWIW, I just built fresh from CVS, and webmail.luther.edu's compose function is 
now real-time.  I even tried typing in a whole bunch of characters as fast as 
possible and there wasn't even a bit of lag.  Well done, and thanks! :)
*** Bug 110325 has been marked as a duplicate of this bug. ***
*** Bug 119318 has been marked as a duplicate of this bug. ***
*** Bug 128557 has been marked as a duplicate of this bug. ***
*** Bug 128658 has been marked as a duplicate of this bug. ***
*** Bug 143873 has been marked as a duplicate of this bug. ***
*** Bug 145194 has been marked as a duplicate of this bug. ***
*** Bug 149580 has been marked as a duplicate of this bug. ***
Blocks: 94576
Blocks: 123623
*** Bug 123623 has been marked as a duplicate of this bug. ***
Blocks: 83841
Blocks: 60371
Marking this bug FIXED!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Keywords: mozilla1.0.1, nsbeta1
Resolution: --- → FIXED
Whiteboard: [FIXED_ON_TRUNK]
Target Milestone: mozilla1.0 → mozilla1.1alpha
Just a little additional feedback (not to rain on anybody's parade!), but I gave
it a try on my workstation here at IBM today, and while the composing on
Luther's Webmail app was much faster than it was, it's still a bit short of
real-time.  The characters don't lag too far behind, but it's still noticeable
(in contrast to this Bugzilla form, which can easily keep up with me); they also
seem to batch-update (many characters appear in clumps).

So, much better (and FIXED on a faster machine than this, such as my home box
that's 1.2GHz with 512 MB of RAM), but my NT 4.0 SP6 (192 MB RAM, but I'm not
sure of the speed specs) box here at work is just a bit draggy on it.

Be that as it may, though, thank you very much for all your work; it's a whole
lot better than it was! :)
Mark, I'd be interested to find out how fast your pc is and what kind of video
card you have. On my 1Ghz Laptop (512Mb RAM, ATI Mobile video card) I'm not
seeing any delay, things show up realtime, even with 100K worth of data in the
Luther textarea!

Also, what build are you using? One from this morning06/14/02 after 8am?

It also might be helpful if you could give us some example of what text you have
in the textarea at the time you see the slowdown.
I still use 1.0.0 with Mac OS X.

What I find is that using a simple Logitech mouse with no specifical driver for
it, the slowness is MUCH less (but it is there).

Slowness becomes annoying when I use the Wacom Tablet (driver 473 a2), and it is
a very slow slowness.
Apparently (thanks to a fair amount of searching on my computer for where NT4
keeps hardware info :) ) this workstation is a 450MHz Pentium II.  It has 192MB
of RAM.  The video card is reported as an S3 Integrated Trio3D (Windows reported
0MB of video memory, although that's obviously bogus :) ).  It happened with an
empty text area, just typing in whatever I chose to type in.  The delay used to
be about a second per character, and now it's down to lagging just a hair behind
my typing speed (slightly more than the Location Bar does, which makes it
perceptible).  I'm using build 2002061404 (4 AM, I believe).  There was no 8 AM
or later build for Windows when I downloaded this one.  Could that make a
difference (even though all of your checkins were in by then)?

Hope this helps. :)
*** Bug 152137 has been marked as a duplicate of this bug. ***
Comment on attachment 87306 [details] [diff] [review]
Patch for nsBlockFrame.cpp and nsBox.cpp

Just wanted to add a note that mentions that this patch for nsBlockFrame.cpp
and nsBox.cpp hides underlying problems like those in bug 111848 and bug 145543
because it prevents reflows from leaking out of the text widget. This gives the
appearance that those bugs are fixed.
*** Bug 141125 has been marked as a duplicate of this bug. ***
*** Bug 153031 has been marked as a duplicate of this bug. ***
*** Bug 153140 has been marked as a duplicate of this bug. ***
the above 3 patches have been landed on the chimera branch
*** Bug 141125 has been marked as a duplicate of this bug. ***
Hi there,

I filed bug #141125 because of problems typing characters in a datafield located
on the following page:

http://support.acer-euro.com/faqs/faqsearch.html

The bug has been duped because of this one but using the newest build I still
see this slow-down while typing stuff :o(

Can anyone confirm this behaviour or do I have a problem on my side?
I just checked

  http://support.acer-euro.com/faqs/faqsearch.html

and it is much faster now with a recent trunk build. Try downloading a nightly
build after 06/13/02 from:

  ftp://ftp.mozilla.org/pub/mozilla/nightly

The build I'm using here right now is 

2002070108

This should be ok - shouldn't it?

btw: the machine I'm on is a P-III 500 with 512 MB RAM...
Additional information:

I just checked the links provided in comment #33 and comment #40 - both pages

http://www.wikipedia.com/wiki/September_11,_2001_Terrorist_Attack/New_York_Times_stories&action=edit

and

http://students.luther.edu/~andersma/Webmail.html

work fine with the build I'm currently using...
Blocks: 147481
petersen: can you pls verify the fixes ont he trunk? thanks!
Blocks: 156522
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [FIXED_ON_TRUNK] → [adt2 RTM] [FIXED_ON_TRUNK] [ETA 07/15]
FYI, this bug introduced regression bug 151882. Fixing 151882 requires some
re-working of the numerous points we turn off and on the caret during editing
and painting. I've already started some of that work as part of bug 54153.


I don't think we need to mark this bug as needing to go into the branch.  If I
fix the regression issues for bug 156522, I'll just produce a branch patch for
that bug that includes the nsBox.cpp changes from attachment 87306 [details] [diff] [review].
*** Bug 123623 has been marked as a duplicate of this bug. ***
Comment on attachment 87307 [details] [diff] [review]
3rd pass for async reflow, painting, and scrolling

a=chofmann for 1.0.1. add the fixed1.0.1 keyword after checking into the branch
Attachment #87307 - Flags: approval+
Keywords: mozilla1.0.1 → mozilla1.0.1+
Comment on attachment 87306 [details] [diff] [review]
Patch for nsBlockFrame.cpp and nsBox.cpp

a=chofmann for the branch
Attachment #87306 - Flags: approval+
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
drivers' approval. pls check this in to the 1.0 branch, then replace
"mozilla1.0.1+" with "fixed1.0.1". thanks!
Keywords: adt1.0.1+
Whiteboard: [adt2 RTM] [FIXED_ON_TRUNK] [ETA 07/15] → [adt2 RTM] [FIXED_ON_TRUNK] [ETA 07/22]
checked in attachment 87306 [details] [diff] [review] to the 1.0 branch.
Keywords: mozilla1.0.1+ → fixed1.0.1
Verified on the 2002-07-18-13 trunk (Win ME) and 2002-07-22-08 trunk (0S X).
Status: RESOLVED → VERIFIED
Verified on 2002-07-22-05 branch
Keywords: verified1.0.1
Blocks: 158782
*** Bug 151853 has been marked as a duplicate of this bug. ***
*** Bug 124714 has been marked as a duplicate of this bug. ***
Blocks: 95346
I'm thinking of temporarily disabling the async reflow, painting and scrolling
changes made in attachment 87307 [details] [diff] [review] for mozilla1.2 since I haven't had time to
address some of the regressions/annoyances people have been reporting. The
reports fall into 3 general categories:

  1. Typed text lags in text widgets, especially in the URL bar. (Bug 158782)
  2. Caret flashes at start of line when deleting. (Bug 151882)
  3. Updating textfields via JS causes flashing. (Bug 165130)

It should be noted that the fix for bug 163528 hides the lag on Win32 platforms
by forcing syncronous reflows and paints at the widget level for better dhtml
performance.
Blocks: 151882, 165130
Attachment 87307 [details] [diff] can be disabled by simply leaving out the
eEditorUseAsyncUpdatesMask when initializing the text widget.
Comment on attachment 101640 [details] [diff] [review]
One line patch to disable attachment 87307 [details] [diff] [review] (with comments)

r=brade
Attachment #101640 - Flags: review+
Comment on attachment 101640 [details] [diff] [review]
One line patch to disable attachment 87307 [details] [diff] [review] (with comments)

sr=sfraser
Attachment #101640 - Flags: superreview+
Comment on attachment 101640 [details] [diff] [review]
One line patch to disable attachment 87307 [details] [diff] [review] (with comments)

a=brendan@mozilla.org for 1.2beta.  What's the deal with bug 151882?  Anything
to do there for 1.2b or 1.2?

/be
Attachment #101640 - Flags: approval+
Duh, never mind my question about bug 151882.  I was wondering if there was
anything more to do for 1.2b than this one-line commenting-out patch.

/b
Blocks: 1.2
Attachment 87307 [details] [diff] (3rd pass for async reflow, painting, and scrolling) has been
temporarily disabled on the TRUNK with attachment 101640 [details] [diff] [review]:

    mozilla/layout/html/forms/src/nsTextControlFrame.c  revision 3.97

Bug 174823 has been filed to track re-enabling it.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Doh, I accidentally re-opened this bug, re-marking fixed/verified.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Restoring VERIFIED resolution.
Status: RESOLVED → VERIFIED
Typing is so extremely slow in all text fields and URL field - it makes Mozilla
unusable. Letter appear one by one like mollases!!!!!

Please fix this bug - I reported it over 2 months agi and still - teh problem
persists. It is gruelling typing this report!

When typing CPU usage hits 100% at all times.

Mac OS X 10.2.1
1.2G RAM
Mozilla 1.2b
C Posey: what hardware are you running? Typing is fine for me on Mac OS X 10.2
on various machines.
Well - and there are still the problems reported in bug #141125 and comment #75,
which might deal also with this bug also... Can someone please verify the page
mentioned in bug #141125 together with an NT 4.0 machine?
*** Bug 175528 has been marked as a duplicate of this bug. ***
I use Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2b) Gecko/20021014
Phoenix/0.3

Exspecially when using the backspace key. Then I also see a cursor flickering at
the beginning to the line.
I can't see how this is "verified/fixed".  Sure it does seem to be better than
it was (which was pretty much unusable for anything more than one line) but it
still is slower & consumes way more CPU than it should.

When composing short documents, it seems to be fine.  But as you type (aka in a
webmail window) it gets increasingly slow.  Holding down the backspace key (to
delete a line just pegs the CPU and is still slow).  Typing text should't
consume between 20-50% of the CPU with no other tasks running.

Mozilla 1.3a / OS X 10.2.3 / 800Mhz G3 / 640MB RAM
I also notice very similar behavior on Linux and XP so this appears to be in the
core code.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: