Closed Bug 141900 Opened 23 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: 23 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: 23 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: