You want to AvoidMultiplePrimitiveGraphicCommands to reduce communication overhead.  However, even if your graphics API can BufferGraphicCommands and your program issues AggregateGraphicCommands, the API must still marshall commands and their parameters and transmit them to the display manager.  

Furthermore, the operating system, display manager and graphics API shield your client code from having to know specific details of the graphics hardware.  Thus the display manager must convert the drawing commands it receives into a form that is most applicable for the graphics hardware that it uses.

'''The communication and interpretation of parameters to drawing commands is time consuming and reduces interactivity.'''

Therefore:

'''The display manager should compile a sequence of graphics commands into a form that is most useful for the graphics hardware and store the compiled form to be invoked later.'''

The display manager compiles a command sequence sent from the client and returns an identifier.  The client can then invoke the compiled command sequence by sending only the identifier.  This reduces the amount of information that needs to be sent over the network.

Because the display manager has knowledge of the graphics hardware, it can compile the command sequence into the most appropriate form for the hardware.  It might even be able to store the compiled form on the hardware itself, thereby reducing communication overhead between the display manager and the graphics hardware (e.g. reducing usage of the system bus).

The client must be able to compile graphics commands at a high level of abstraction, both the allow programmers to easily make use of the facility, and to allow the graphics hardware the greatest leaway in optimising the compiled form.  For example, an early version Microsoft's Direct3D defined a low-level machine language to specify CompiledGraphicCommands.  However, this language did not match that any existing hardware, and was too low level to be efficiently compiled to the code of existing graphics chip-sets.  CompiledGraphicCommands defined in this language were hard to program and slow to execute; support for this feature was dropped from later versions of Direct3D.  The latest versions of Direct3D have a higher level interface to programmable graphics hardware which has been much more successful.

However, in order to use CompiledGraphicCommands, clients must first create and compile sequences of graphic commands that they need.  This adds additional logic to the client code.

The graphics created by CompiledGraphicCommands are typically static, and so the pattern is not applicable for graphics that depend on dynamic state.


Known uses include:
	* '''Sun NeWS''' clients could send Display PostScript code to be executed on the server.
	* '''MacOS X''' uses PDF rather than PostScript to send code to the display manager.
	* '''OpenGL''' can record sequences of drawing commands into "display lists" stored in the display manager. SGI's software OpenGL renderer for Windows compiled display lists into Pentium machine code. OpenGL hardware drivers generate code for specific graphics chip-sets. 
	* '''Direct3D''' has a high level interface to programmable graphics hardware.
	* '''OpenGL 2.0''' will include a high-level "shading" language for programming graphics processors.  High-level in this case is compared to the current techniques of writing routines in assembly language for each graphics chipset; the shading language looks a lot like C.  http://www.3dlabs.com/support/developer/ogl2/index.htm
	* NVidia have also released a high-level shading language based on C called Cg (C for Graphics).  http://www.cgshaders.org/

----
Also see GraphicsPatterns.

CategoryGraphicsPattern CategoryPattern CategoryOptimization