Avoid Multiple Primitive Graphic Commands

From AvoidDrawing...

Lean on the driver. For example, most drivers offer both a Line primitive and a PolyLine method. The latter also goes straight thru the blitter, and is tons faster. So the actual rule is "AvoidMultiplePrimitiveGraphicCommands."

Good point, but two different patterns. AvoidDrawing to reduce the overhead due to moving data, avoid multiple primitive graphic commands to reduce communication overhead between the display manager and its client programs. To do so, a program can either issue AggregateGraphicCommands or let the graphics API BufferGraphicCommands.

There's a general point here about RISC versus CISC. For example, the Dolphin guys reckon a CISC Smalltalk interpreter is best to minimise the interpretation overhead.

A RISC approach improves performance if reducing the number of operations significantly improves the speed at which the remaining operations can be dispatched. In graphics programming, that is not the case -- the performance bottlenecks are caused by the communication overhead between the client and the display server and the data-copying required to blit and draw into raster memory.

If that's really the case, then the best solution might be to download the program that displays the graphics to the display server. Like Sun's NeWS used to do. In a sense, the single "primitive" has become "execute this Postscript program and let it draw on the screen".

This approach is also taken by MacOS X, which uses PDF rather than PostScript, and OpenGL, which 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 probably generate code for specific graphics chip-sets.

[I have written this pattern up as CompiledGraphicCommands --NatPryce]

Better than an interpreter local to the display server is compiled code that marshals the drawing primitives with as little overhead as possible. I think that is at least one reason why X11 bested NeWS.

AFAIK, the reasons why X11 bested NeWS were completely non-technical (basically, NeWS cost $1xxx for the most basic version, while X11 was free. And Sun was the owner of NeWS, and all the other *nix companies were afraid that Sun would play a microsoftie on them.) -- StephanHouben

Marshalling is one part of the communication costs, with transport/network protocol processing and physical communication costs being the other parts. Graphics APIs that were originally designed to be network-transparent (X11, OpenGL etc.) often provide primitives that are easy to marshall. OpenGL, for example, allows a program to send a chunk of data to the display manager and specify how the driver should step through the data to find various parameters. However, functions like these only work well with low-level languages. A Java program, for example, would have to assemble the chunk of data itself to use this function, and so the function just punts the marshalling problem over to the application programmer.

Also see GraphicsPatterns

CategoryGraphicsPattern, CategoryPattern