Neil Hodgson wrote:
Robert Roessler:
It may be possible to "fix" this by doing the following: when I get to the last step of a multi-step undo/redo, IF I "know" that I have deferred some screen updates, THEN force a full screen/scrollbar repaint. Do you think this will work - in the "logically correct" sense?
There are some other problems such as the wrap code using the position to indicate where it should invalidate wrapping data. You lose this if it only sees the final step.
A flag indicating if any of this batch has had lines added or deleted could be used for two of the checks. SC_MOD_CHANGEMARKER should not be set at the same time as mh.linesAdded. The logic here is a bit tricky so may require further tweaking. If you feel it is worth expending time then it should be OK.
I have finished a version of Editor::NotifyModified Undo/Redo "optimizations"... it would be good if you could check it over WRT "safety"/"correctness" assumptions.
Basically, I added NotLazyEval and MustEvalForUndoRedo functions to be used as predicates before performing some potentially expensive visual update functions.
Highlights of the changes (in Document.cxx, Editor.cxx, and iface):
0) I left the wrapping code alone for now :) 1) added the SC_MULTISTEPUNDOREDO mod flag (0x80) 2) adjusted SC_LASTSTEPINUNDOREDO implementation to match doc 3) "&& NotLazyEval(mh)" is added to checks before SOME visual updates 4) "MustEvalForUndoRedo(mh)" at end of updates - catch "deferred" ones
One of the "optimizations" my be controversial (i.e., wrong), but I am suppressing visual updates on the "before" insert/delete cases, since the "real" inserts/deletes will be seen *very* shortly. Is this reasonable?
Taken together, this handles the changes (mostly in Undo/Redo) that appear "safe" to me [with fairly small code changes]... I would like to generalize some of this to the larger case(s) of sequences of overlapping visual updates, but the framework at present does not seem adequate to accumulate visual updates and then apply them as a group.
OTOH, some of this happens "for free" in the Windows graphics code - I would imagine that GTK/GDK tries to do the same, but I do not know this to be the case.
I am not sure precisely what you mean with the "flag indicating if any of this batch has had lines added or deleted could be used for two of the checks" - but if it means less screen updating, I am ready! :)
A zip with Document.cxx, Editor.cxx, and Scintilla.h (yup, just the .h) is available at
http://www.rftp.com/lazy.zip
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
