Open Bug 83841 Opened 19 years ago Updated 9 years ago

SetValue on nsHTMLInputElement is too slow

Categories

(Core :: Editor, defect, P3)

defect

Tracking

()

Future

People

(Reporter: hyatt, Unassigned)

References

Details

(Keywords: perf)

One of the big differences between SeaMonkey and WinEmbed is the time it takes 
to update the location bar.  On SeaMonkey I've seen this consistently take 
between 20-40ms.  

Drilling down into the code it looks like the expensive part is a synchronous 
update to the view manager. EndUpdateViewBatch is the expensive function here.

Any reason why this has to happen synchronously?  We hold up the world while we 
synchronously update the location bar.
Keywords: perf
looking at 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/view/src/nsViewManager2.cpp
and 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/base/nsEditor.cpp

I'm cc'ing Simon and reassigning to kmcclusk, hopefully they can give some 
insight to the problem
Assignee: beppe → kmcclusk
"looks like the expensive part is a synchronous update to the view manager"

I dont know why it needs to be synchronous? Can we try changing the argument in
the call to EndUpdateViewBatch in nsEditor.cpp to NS_VMREFRESH_NO_SYNC and test
it. Making it synchronous forces painting to occur when the EndUpdateViewBatch
is called which is seldom what is wanted. The only reason I can see for making
it synchronous is if we were starving the event queue and paints were not
happening. (But that would cause other problems). 
Yes, the reason I assigned this to editor and not to Kevin was that it seems 
like the error here is that the call itself (in Editor code) synchronous. 
Beth: Can we try changing the argument in the call to EndUpdateViewBatch in
nsEditor.cpp to NS_VMREFRESH_NO_SYNC and test it?

Assignee: kmcclusk → beppe
ok -- assigning to jfrancis, cc kin and simon (they had there fingers in there too)
Assignee: beppe → jfrancis
Priority: -- → P3
Target Milestone: --- → mozilla1.0
I agree that we shouldn't be using a synchrous paint, but there are some 
platforms where changing to NO_SYNC may be problematic, for example on Linux, 
gtk batches async paint requests until the system is idle, this starts to look 
funny if you type fast. You'll see the caret move around (because it's drawing 
directly to the screen) but none of the text you type shows up until you stop 
typing. It gets even more noticeable when typing in tables. (Example the 
homepage for www.mozilla.org)

Maybe editor should do different things depending on whether we're handling 
typing, or en-mass setting of the editor content.
assigning to kin for now; no real won to me owning this one at this time.
Assignee: jfrancis → kin
Blocks: 91351
Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.
Target Milestone: mozilla1.0 → mozilla1.0.1
One of the patches in 141900 makes text widgets use async reflow, painting, and
scrolling. So can I close this out now?
Status: NEW → ASSIGNED
Depends on: 141900
Target Milestone: mozilla1.0.1 → mozilla1.1alpha
Marking this fixed since we now use async reflows and updates for text widgets.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
rs vrfy, but do reopen if it's still an issue.
Status: RESOLVED → VERIFIED
We still have bug 190147, which is about textareas. Also, I think the async
reflow/update stuff was turned off. Kin, should this be reopened?
OS: Windows 2000 → All
Hardware: PC → All
Yup.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla1.1alpha → Future
Depends on: 174823
QA Contact: sujay → editor
Assignee: kinmoz → nobody
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.