Minimize display overhead and flicker with DeferredUpdate. Conceptually similar to an old-fashioned display-list graphics engine, a display processor receives and satisfies display requests, eliminating the need for applications to write the screen themselves. 

The Display Processor, with knowledge of the physical display geometry, computes intersections of the requests and maintains a list of the display regions that require update. Requests that paint the same region multiple times can be scheduled and optimized without requiring actual access to the display or the resulting flicker. The display processor can then repaint portions of the display (or the whole display) in response to requests from the window system or hardware.

This approach is particularly helpful for scheduling display access from multiple parallel processes or threads.

Discovery is attributed to MarkCantor in early (original?) MacroMind versions. (It was used in the original MacOperatingSystem, so I guess that predates MacroMind).
----
This same technique is used in some editors to avoid slowing down processing that comes by having to update the display with the results of each of a long sequence of edit commands.  The slowdown comes when the sequence of commands are actually sub-commands embedded in a higher-level command.  

This type of higher-level command comes about in two ways.  The easier of the two to see is when a user creates a macro of sub-commands.  For editors without deferred update, it's painful to watch the screen crawl when each sub-command updates the screen and the sub-commands are much faster than the screen updates. With deferred update, the macro could run an order of magnitude faster. The more insidious of the two ways higher-level commands come about is through the efforts of a good designer. The primitive operations of the editor are treated as building blocks for more complex editor operations.  This produces the usual increase in productivity during editor development -- a good thing.  

But if the primitives perform their own redisplay, as say their last official act, then as more and more complex operations are constructed the display updates begin to take up more time.  Of course, complex operations at compiled speeds don't show the slowdown due to immediate display update the way interpreted macros do.   

If the deferred update concept is not introduced early into the design process, then very quickly the size of the project -- especially one building on primitives -- will prohibit its introduction.  No developer wants a massive rewrite of the code to retrofit it with anything, deferred update included -- especially when the slowdown is "acceptable" in complex operations given the current product delivery schedule.  And only a small percentage of users, the so-called "power" users, make extensive use of macros, anyway.  

For those who want to see how deferred update can be done in an editor, Emacs is a good model.  It used this technique in the old days to overcome interpretive speeds and dinosaur processors in support of user-extensibility.

-- ChuckSiska

----

Also known as Dirty Rectangle Caching. Can easily be combined with IdleUpdates. Also see GraphicsPatterns.

----
CategoryGraphicsPattern CategoryPattern