In most graphical systems, display manager is in a separate address space from the client programs that use it to display their output.  The display manager may be implemented as a service of the kernel, as a separate user-space program on the same host, or be accessed over the network using a communication protocol such as X11 or GLX.

'''Passing a client's drawing commands to the display manager is time consuming and reduces interactivity.'''

Passing data between user space and kernel space requires a trap into the kernel, which is time consuming.  Passing data between two user-space processes requires two traps into the kernel, and additional data copying.  Passing data across the network also involves communication overhead and the overhead due to protocol processing to achieve reliability and flow control.

These overheads are increased if a reply is required from the display manager.

Therefore:

'''Implement drawing commands as asynchronous requests, and buffer requests in the client until multiple commands can be sent in a single block.'''

Drawing commands cannot return a result to the client code, so that it does not matter exactly when they are sent to the display manger.  When a client sends a query to the display manager, and expects a reply, it must flush all buffered commands before they are sent.

This reduces the overhead per command caused by communication between the client and the display manager.

However, the graphics API is now more complex:
	* If a command causes an error, it is reported when the command is sent, not when it is issued. Exception handling cannot be used to handle errors.
	* Clients must understand how commands are buffered and flushed in order to make the most efficient use of the display manager.  For example, they should avoid mixing commands and queries.  They may also need to explicitly flush the buffer in order to force timely updates to the display.

Client programs can also use AggregateGraphicCommands to reduce communication overhead.

Known uses include X11, OpenGL and the Win32 API.

----
Also see GraphicsPatterns

CategoryGraphicsPattern CategoryPattern CategoryOptimization