Closed
Bug 48758
Opened 24 years ago
Closed 24 years ago
text input handling is so slow on linux that it is unusable
Categories
(Core :: DOM: Editor, defect, P1)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: yashi, Assigned: anthonyd)
References
Details
(Keywords: perf, platform-parity, Whiteboard: [nsbeta3+][p:1][PDTP1]FIX IN, RE-TESTING)
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.
Comment 1•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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
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
Comment 4•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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).
Comment 8•24 years ago
|
||
linux builds are so slow that they are pretty unusable at this time
Severity: minor → major
Keywords: pp
Priority: P3 → P2
Summary: text input handling is so slow. → text input handling is so slow on linux that it is unusable
Whiteboard: [nsbeta3+][p:2]
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
Comment 10•24 years ago
|
||
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
Assignee | ||
Comment 11•24 years ago
|
||
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]
Comment 12•24 years ago
|
||
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]
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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.)
Comment 15•24 years ago
|
||
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)...
Comment 16•24 years ago
|
||
53718 is fixed (typo: moodifiers!), now we have 53760 as a regression caused by this. i believe it should also be straightforward to fix.
Assignee | ||
Comment 17•24 years ago
|
||
i will re-quantify. this is great news. anthonyd
Comment 18•24 years ago
|
||
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.
Assignee | ||
Comment 19•24 years ago
|
||
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
Reporter | ||
Comment 20•24 years ago
|
||
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!
Assignee | ||
Comment 21•24 years ago
|
||
Resolving this bug as fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 23•23 years ago
|
||
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.
Description
•