text input handling is so slow on linux that it is unusable

VERIFIED FIXED in M18

Status

()

Core
Editor
P1
major
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: yashi, Assigned: anthonyd)

Tracking

({perf, pp})

Trunk
x86
Linux
perf, pp
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][p:1][PDTP1]FIX IN, RE-TESTING)

(Reporter)

Description

17 years ago
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

17 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

17 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
Assignee: beppe → anthonyd
Keywords: perf
Target Milestone: --- → M19
(Assignee)

Comment 3

17 years ago
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

17 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.

Comment 5

17 years ago
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).
(Assignee)

Comment 6

17 years ago
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

17 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

17 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]
(Assignee)

Comment 9

17 years ago
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

17 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

17 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

17 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]

Updated

17 years ago
Blocks: 50440

Comment 13

17 years ago
we're working on this. see bug 52359, 47395 and others (uh, just look at my
assigned and cc'ed bugs...)

Updated

17 years ago
Depends on: 52359
Whiteboard: [nsbeta3+][p:1][PDTP1] → [nsbeta3+][p:1][PDTP1]WORK IN PROGRESS

Comment 14

17 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

17 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

17 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

17 years ago
i will re-quantify.  this is great news.

anthonyd

Comment 18

17 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

17 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

17 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

17 years ago
Resolving this bug as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
verified in 9/28 build.
Status: RESOLVED → VERIFIED

Comment 23

17 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.