Closed Bug 345048 Opened 15 years ago Closed 14 years ago
Scrolling with spellchecked words visible is slower
Scrolling a large textarea quickly with the scroll thumb seems to be slower with misspelled words are visible. Open a large textarea, for example, go here: https://bugzilla.mozilla.org/attachment.cgi?id=227870&action=edit and click "edit attachment as comment," or: http://en.wikipedia.org/w/index.php?title=Jimi_Hendrix&action=edit The first part of the text will have a lot of misspellings, but the rest won't because we've hit the maximum number of misspellings. Scroll quickly with the thumb. At the top where there are misspellings, scrolling is slower. At the bottom, it is faster. Turning off spellchecking for the field makes it all fast.
Everything happens slower in the box. When you right-click on a marked word, the context-menu appears slower, when you click on an item, the menu disappears slower.
Salient points: Total hit count: 132794 Count %Total Function Name 29376 22.1 nsAttrAndChildArray::IndexOfChild(nsINode*) const 14684 11.1 _end 8722 6.6 nsVoidArray::InsertElementAt(void*, int) 5514 4.2 nsRange::IsIncreasing(nsIDOMNode*, int, nsIDOMNode*, int) Of the 132794 hits, 112081 are under nsTextFrame::PaintUnicodeText. This breaks up as: 112081 nsTextFrame::PaintUnicodeText(nsPresContext*, nsIRenderingContext&, nsStyleContext*, nsTextPaintStyle&, int, int) 67522 nsFrameSelection::LookUpSelection(nsIContent*, int, int, int) 29867 nsRenderingContextImpl::DrawString(unsigned short const*, unsigned int, int, int, int, int const*) 7385 nsTextFrame::PaintTextDecorations(nsIRenderingContext&, nsStyleContext*, nsPresContext*, nsTextPaintStyle&, int, int, int, unsigned short*, SelectionDetails*, unsigned int, unsigned int, int const*) 4807 .L1149 1348 nsTextFrame::PrepareUnicodeText(nsTextTransformer&, nsAutoIndexBuffer*, nsAutoTextBuffer*, int*, int, int*, int) LookupSelection spends all its time in our old friend nsRange::ComparePoints.
So the basic problem, I think, is that for every text frame we do hundreds of range inclusion comparisons here. There's just _got_ to be a better way of doing this. One thing that comes to mind is sorting the selection ranges by end point (and start point?) and keeping a cached "last looked up range" thingie so that LookUpSelection starts looking at a reasonable spot and can quickly decide when to stop...
So even with my IsIncreasing patch doing a ComparePoints is a non-trivial amout of work. So even if I would be able to double speed up ComparePoints (which i think is doable) it doesn't look like that'd be a significant win (30000 out of 130000 Hits).
Well. It's a 25% speedup in scrolling. More importantly, its a 50% reduction in the difference between scrolling while spell-checking and just scrolling... That assumes we don't make algorithmic changes to just reduce the number of calls to ComparePoints. Like I said in comment 3, I think we should think about ways to make such changes.
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1beta2
Fixed by bug 345099.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: fixed by 345099 which has patch
You need to log in before you can comment on or make changes to this bug.