Neil Hodgson wrote:
Armel Asselin:
... generally, a painting system is transaction oriented, i.e., open a transaction, do all the job (computing the bound box of things to update and accumulate draw related updates somewhere, or bailing out if too many, noting that with a 'redraw everything' flag), close the transaction: if something was to be updated, do it
The case where this does not work well is scrolling. When you scroll the window, all the lines on the screen need to change so the bounding box is the whole window. Redrawing the whole window is quite slow and the window already contains many correct pixels that are just in the wrong position. So the scrolling code performs a *synchronous* blit to move those pixels to where they should be and then fixes up the newly scrolled in pixels. This has to be synchronous as otherwise multiple scrolls occurring before a paint become very confusing as you don't know which pixels are still valid.
Edit widgets that do not do this are generally too slow to use. For an example, the C# version of SinkWorld/Tentacle does not perform synchronous scrolling as Windows.Forms has no equivalent to ScrollWindow.
While all of this is semi-believable, this does not seem to be what is happening... what *is* happening is that in Editor::SetScrollBars(), SetVerticalScrollPos() is called, followed by a [full] Redraw() every time.
There is a continuous cycle of BasicDeleteChars, NotifyModified, SetScrollBars, ModifyScrollBars, SetVerticalScrollPos, ExposeMain, and Expose - for EACH of the lines being deleted, but only if they would be viewable.
OTOH, the cycle is only BasicDeleteChars, NotifyModified, and SetScrollBars, ModifyScrollBars in the case where the lines being deleted are not visible...
Muwahahaha... how about this: Obviously Neil knows what is up with SC_LASTSTEPINUNDOREDO, but it *seems* to be just what I wanted! I wanted a way of telling when you are at the "end" of an Undo/Redo sequence, so that calling SetScrollBars could be deferred until then... and it looks like Scintilla has this exact feature already present internally - but not apparently being used. Hmmm. Anyway, I modified the "if" in Editor::NotifyModified that would *always* do a SetScrollBars call if lines had been added/deleted, so that IF you are doing an UNDO/REDO AND are NOT on the last "step" of the sequence... DON'T call SetScrollBars [until you are]. :)
It appears to work fine, but I look forward to hearing from Neil that a) this will work, or b) "X" is why he wasn't using this flag.
WAS:
if (mh.linesAdded != 0) {
SetScrollBars();
}CHANGED TO:
if (mh.linesAdded != 0) {
if (mh.modificationType & (SC_PERFORMED_UNDO|SC_PERFORMED_REDO)) {
if (mh.modificationType & SC_LASTSTEPINUNDOREDO)
SetScrollBars();
} else
SetScrollBars();
}Note that the tabs were replaced by spaces to fit here. :)
Robert Roessler [EMAIL PROTECTED] http://www.rftp.com _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
