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

"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?

ok -- assigning to jfrancis, cc kin and simon (they had there fingers in there too)

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.

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.

One of the patches in 141900 makes text widgets use async reflow, painting, and scrolling. So can I close this out now?

Marking this fixed since we now use async reflows and updates for text widgets.

rs vrfy, but do reopen if it's still an issue.

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?

Yup.