I've been having a look at the vertical scrolling code in
Editor::ScrollTo. I can see that some optimization can be done in
the various platforms if the number of lines scrolled is ten or
less. I wonder why this is limited to ten lines? I can imagine
cases where a scroll of greater than ten lines but less that an
entire page might be generated which could benefit from some
optimization.
Its possible but there is a trade off between different costs here
as performing a window scroll may require reading and writing a large
number of pixels if the scroll operation isn't handled by lower level
code. The big wins are for the common cases where a scrolling is by a
line or two. A better value could be arrived at by retaining
statistics and choosing the expected lowest cost. Alternatively,
instrument up a copy and see what the costs are on your platform.
I had thought that it was more a case of diminishing returns. My
assumption is that scrolling the widget is always faster than
rendering text. If any part of the view can be copied then there is
something to be gained. Does that oversimplify?
I imagine a case where 30 lines are visible on the screen. If a
mouse wheel event generates a scroll of 20 lines then I would want
the pixel information for the remaining 10 lines to be copied and 20
lines to be rendered new. It seems like a gain but there may be some
additional costs in getting up that machinery to do a widget scroll.
One thing more. In that same function invalidating the caret causes
an entire redraw when the caret is in the scrolled area. This
doesn't seem necessary and hurts scrolling performance when the caret
is visible.
Handling the caret while scrolling was quite tricky as it is often
the caret moving that is causing the scrolling. The old caret needs to
be removed and the new caret drawn. I'd like to see better performance
but would want to see some evidence that all cases were considered.
Well, that's a good point. I certainly haven't considered all of the
implications on the various platforms.
Scroll performance wouldn't worry me too much, but I'm trying to put
two scintilla editors inside of a diff tool. These kind of costs
start to add up when scrolling both views together.
Jason
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
