You are writing a graphical program that uses DeferredUpdates to optimise refreshing the display. Your program uses an event-driven display manager, such as the X Window System or the Win32 API.
How do you control when a DeferredUpdate gets drawn?
Updates are usually generated in response to user input. User input is slow compared to the speed of the computer, and users don't notice if graphics updates are delayed by 100 milliseconds or less.
Therefore:
Perform each DeferredUpdate when there are no more user input events to process.
This can be easily detected by querying if the event queue is empty.
The Win32 API provides this as part of its message handling algorithm. User input events have a higher priority than WM_PAINT messages. Most X11 toolkits, such as Tcl/Tk, Xt or Gtk, can register callbacks to be invoked when the event loop is idle. These are most often used to implement IdleUpdates to the screen or to the layout of widgets in a layout manager.
Java manages this automatically. A component schedules a DeferredUpdate by calling its repaint method. The AWT event thread will, eventually, call the component's paint method. However, there is no guarantee that the paint method will actually be called when the event loop is idle.
The ReactorPattern can be used to dispatch events that are not caused by user input, such as I/O streams, sockets, timer events, interprocess semaphores, message queues, pipes, signals etc. The event loop can (should?) also dispatch these events before invoking IdleUpdates. However, one must be careful that an event source is not continuously delivering events. That will stop IdleUpdates from running, and may also stop other events being delivered. E.g. event sources should be "edge triggered", rather than "level triggered".
When I saw this page title I thought it referred to the tweaks made to random bits of code made while mulling over some other problem.
Also see GraphicsPatterns.
CategoryGraphicsPattern CategoryPattern