Neil Hodgson wrote:
Robert Roessler:
Like I said, I assume you would know... but, might you now be willing to see SC_LASTSTEPINUNDOREDO in the larger context of "which operations that do not change buffer (text OR style) contents could be reasonably deferred until the end of this undo sequence?" There may be more candidates for this type of platform-independent optimization.
I have never experienced an undo operation that is slow enough to cause concern. There are other things that I sometimes find too slow and I'd be more likely to look into them.
Like I have said all along, I realize that the "performance" problem I encountered was a "pathological" case... that being said, it is still true that whenever one is "batching" a large number of line-count changing updates into a single undo/redo sequence, things can get ugly with a lot of [superfluous] "micro" display updates.
The proposed patch does seem a bit narrow to me. It'd be great to really solve the scrollbar so it updated lazily yet was correct whenever the user manipulated it. The scrollbar also causes performance trouble when line wrapping.
Although this probably is not what you meant here, I did make further changes, applying this particular form of "laziness" test to a total of four places in Editor::NotifyModified:
1) the CheckModificationForWrap is now "lazy" WRT undo/redo 2) the "mh.linesAdded != 0" Redraw is now "lazy" WRT undo/redo 3) the "mh.linesAdded != 0" SetScrollBars is now "lazy" WRT undo/redo 4) the RedrawSelMargin is now "lazy" WRT undo/redo
These *appear* safe (WRT laziness) to me, but await your judgment.
I also note that the whole point of limiting these changes to the "performed" undo/redo modifications is to keep them from effecting actions [more] directly initiated by the user. OTOH, trying to move beyond the undo/redo scenario is more interesting... but you have the much harder problem of defining/detecting these "safe points" between which updates *could* be deferred. I just grabbed the low-hanging fruit. :)
While I realize that the case that was giving me so much trouble might not intersect much with the needs of a more-or-less straight-up text editor like SciTE, the larger undo/redo batching *could* happen in pretty much any custom use of Scintilla as an editing component.
Possibly. I can't recall any other similar issues although people may just drop Scintilla when they have a performance problem.
As you say, this a solution to a "narrow" class of performance problem / opportunity... :) But to recap, the way I got into this spot is not that weird - I am just (in this instance) displaying the output from another process (a compiler), which comes in as a lot of line-at-a-time data, which it seemed natural to wrap in a begin/end undo block.
If you want me to make a real patch for this, I will even comment it.
OK.
I will try and send you code, but even zipped (or LZMA compressed), it is still 40-48 KB... hopefully I will not run afoul of any email gateways. :)
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
