Hum, yes it is not easy I know, however by taking some 'accummulation register' about the moves, it would probably be possible to tell 'OK only this part of old view is reusable, put it there and repaint the remain'. This register would be some kind of span (start/length or start/end) that gets always thiner and thiner each time you move (i.e., shortening it at start or end) and knowing the actual place where it must be placed: from that you'd deduce both what is to be redrawn and what could be saved.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.
I understand however that it is much simpler to do the stuff synchronously. Maybe this register could be 'flushed' (i.e. by doing the actual blit) each time a too complex operation would occur and it would work only for simple move up / move down.
For sure, it could be expanded to be an order list of spans as well, allowing deletion and insertions of lines to still use the screen copy technic more often, but it may become really complex.
Another method would be to maintain a simple array per view, filled each time the view is drawn with for each visible document line its vertical span, then simply move the stuff up and down there, and at the end of the transaction use that to produce the actual blits if any, then repaint the holes.
The last is probably not very complex, I used that in a combo-box style widget (where drawing was really costy on a very bad hardware) and it worked quite well. yet this is still a significant work...
Armel
_______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
