any text box including this description box and url box on the tool bar does not show the text entered right a way. I don't remember since when but it's got slower with in last a few weeks? This mozilla is checked out last night.
yes, text fields are pretty slow. probably related to the fact that they repaint the entire text area whenever 1 character is typed...
Assignee: pavlov → beppe
Status: UNCONFIRMED → NEW
Component: GTK Embedding Widget → Editor
Ever confirmed: true
QA Contact: pavlov → sujay
Anthony, looks like we need to run quantify again and see if something is amiss, cc waterson so he knows that repainting is having issues
Assignee: beppe → anthonyd
Target Milestone: --- → M19
nothing has changed recently to slow text fields any further. They have been slow for quite awhile. I can run some more quantify stuff, but I am 99.9% positive that all its gonna show is that incremental reflow sucks. Anthony
anthonyd: try turning paint flashing on to see what is being repainted. Verify that only the area in the text field is being repainted. If not, then there is a problem with reflows "leaking out of" the text field. buster was working up a fix for this, but I can't remember the bug number.
This might be related to bug 47395?... Trying to isolate typing performance problems related to XUL (if it's just a layout problem, there's no relation).
I tested this with today's build, with paint flash turned on (per waterson) and *mostly* the text area was re-painting. Sometimes, if there was a large amount of text, other areas BELOW the text area in question would repaint also. I'm not positive about what all of this means. I would like to test this on morse wallet page (the one with all the text fields), but I dont know where that is. Anthony
Status: NEW → ASSIGNED
My current guess is that string comparisons got slightly slower during this time (I saw the same radical slowdown that the reporter saw), which caused a big problem due to the enormous number of string comparisons (see bug 47395).
linux builds are so slow that they are pretty unusable at this time
Severity: minor → major
Priority: P3 → P2
Summary: text input handling is so slow. → text input handling is so slow on linux that it is unusable
I test this on windows and it really seems fine, can someone test this on linux for me? Mike and I have profiled this and we found some problems, that werent ender related (ie event handlling in layout, i cant remember anything mroe specific that that, but we will be doing more profile work.) If this ends up being reproducible on linux only, I will need some help from a linux person (like akkana) anthony
Typing is i n c r e d i b l y s l o w w w on linux and has been since about the time this bug was filed. It hasn't gotten any faster recently. Further profiling probably isn't going to help much until bug 47395 is out of the way (at which point we can reevaluate and see if that was the main problem or not).
Depends on: 47395
per beppe, per akkana, this needs to be a p1, linux is not usable without this. this is also dependant on dr and hyatt's bug (47395). adding dr and hyatt to the cc list so they are aware of the situation.
Priority: P2 → P1
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:1]
If this is what it takes to make the Linux build usable, then PDT agrees with P1. Keep in mind, though, that this bug won't prevent us from shipping the product.
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1][PDTP1]
we're working on this. see bug 52359, 47395 and others (uh, just look at my assigned and cc'ed bugs...)
Depends on: 52359
Whiteboard: [nsbeta3+][p:1][PDTP1] → [nsbeta3+][p:1][PDTP1]WORK IN PROGRESS
Ok, the XUL key listener is gone, and we're in an all-XBL world now. Hopefully this will result in a nice improvement on Linux. (On Win32, my debug build after the changes was as fast as my optimized build was before these changes.)
well, we seem to have caused a couple minor regressions here and there (bug 53718 is what i'm looking at now), but besides that, seems ok at first blush. i'll test for a couple days and see how things feel. anthonyd: feel like running those quantify tests again? it would be nice to see how typing behaves percentage-wise now (i.e., who's doomed now)...
53718 is fixed (typo: moodifiers!), now we have 53760 as a regression caused by this. i believe it should also be straightforward to fix.
i will re-quantify. this is great news. anthonyd
anthonyd: be sure not to run into the symptoms of of bug 51392 when quantifying, or it'll throw your profile off with massive reflowing.
bug reporter: can you re-test this? I am no longer seeing this after our XBL improvements. Also, please take a look at a release build, for me the release build was very fast.
Whiteboard: [nsbeta3+][p:1][PDTP1]WORK IN PROGRESS → [nsbeta3+][p:1][PDTP1]FIX IN, RE-TESTING
I don't have access to old pentium 200 which i was using at the time of the report. So, can't really tell how much really improved. :( top indicates that mozilla is using 80% of CPU on duron 600MHz if i hold down one key, say 'a' in text area. typing in Composer on Duron 600 is quick enough for sure. :) thank all of you for the hard work!
Resolving this bug as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
verified in 9/28 build.
Status: RESOLVED → VERIFIED
this fell out of the milestone bucket, setting to m18
Target Milestone: --- → M18
You need to log in before you can comment on or make changes to this bug.