Aggregate Graphic Commands

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.

Each drawing command sent to the display manager incurs communication overhead.

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.

Overhead for each command may be amortised by APIs that BufferGraphicCommands, but sending fewer commands introduces less overhead.

Therefore:

Issue a single drawing command that draws many primitives in preference to many commands that each draw one primitive.

Most graphics APIs provide such AggregateGraphicCommands. For example a program can use the polyline command to draw many line segments, rather than using the line command multiple times.

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

However, the client code is more complex because it must collect the parameters to each aggregate command in arrays or collections. This involves additional logic. Programs written in languages without GarbageCollection must ensure that they reclaim memory used by dynamic arrays of points or lines.

Client programs can also use APIs that BufferGraphicCommands to reduce communication overhead.

Known uses include X11, OpenGL and the Win32 API.

Is there a more general AggregateCommands? pattern that could be factored out of this? There are many areas besides graphics where putting a set of commands (or data elements) into a single message improves performance dramatically by reducing the per-message overhead (network communications, non-video device drivers, interprocess communications, ...)

Yes, I would say that this AggregateGraphicCommands is a specialisation or use of a more abstract pattern for optimising communication between processes or between a process and hardware. -- NatPryce

Compression theory applies, I think. 'A more complex command' is a form of library compression. Compressing adapters exist for simple compression of streams, and can be quite efficient as well as adaptive. All they need is a 'flush' capability to guarantee a message is sent at the required time. Arithmetic coding is particularly useful for this. They complement semantic compression, where the meaning of a combination of commands may imply a simpler set is sufficient. Elevator algorithms for disk drives do this. So I would look at two adaptation/transformation layers. One doing bitwise compression of the datastream, and one doing redundancy elimination on the command stream itself. -- RichardHenderson

I don't think compression theory needs to be brought into it. Any time that there is some sort of per-message overhead, then putting multiple elements into a message is an optimization. For example, if you are using TCP/IP, every packet has a few dozen bytes of header information, and every packet will be padded out to some minimum size. Sending a few dozen bytes in a TCP/IP packet costs no more than sending a single byte, and sending several hundred in a single packet will cost a lot less than splitting it into two or more packets. So maybe an appropriate name for the pattern I'm thinking of would be "MaximizeDataPerMessage?" or something like that.

See AvoidMultiplePrimitiveGraphicCommands, GraphicsPatterns

CategoryGraphicsPattern, CategoryPattern