Open Bug 83841 Opened 19 years ago Updated 9 years ago
Value on ns HTMLInput Element is too slow
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.
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
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla1.1alpha → Future
Assignee: kinmoz → nobody
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.