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)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

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.
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
Keywords: perf
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
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
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]
Blocks: 50440
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
Closed: 24 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.