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:
Known uses include X11, OpenGL and the Win32 API.
Also see GraphicsPatterns
CategoryGraphicsPattern CategoryPattern CategoryOptimization