TkGS Specification - Overview of existing models

X Window

The X Window system uses a platform-neutral, client-server networked architecture. The client side of the application is the computational part, and can live on any machine even without displaying capabilities, from embedded processors to supercalculators. The server side is in charge of the display which is handled by an X server: the client sends X requests to the server, asking to create windows, allocate colors, draw things... The power of X comes from its neutrality: the client and the server can reside on different machines, and even on different OSes. A client can have its display distributed on several servers, and the same machine can act as a client and a server for different applications.

To create a window, clients must provide information about the machine where they want to create it, named the Display, and the color model they want to use (eg. true color, grayscale...) named the Visual. There may be several visuals available on the same server. To draw shapes, the client must provide, along with the Display, the Drawable (ie where to draw) and a Graphics Context (GC) (ie the drawing parameters such as the background color). The Drawable can be a window or an in-memory pixmap. The GC is a structure that is filled with proper arguments, and that must be passed to primitives like XDrawRectangle(). This is a stateless model, as the Drawable does not retain any information about the drawing parameters between calls to primitives.

The Drawable provides a limited device-independance: it is only suitable for display-like pixel devices, as its coordinates system uses integer pixel coordinates. It is not suitable for other devices such as printers that use other coordinates systems

Windows

Windows and the Win32 GDI (Graphics Device Interface) uses a device-independent architecture. There is no clear notion of client and server, as the display can, in practice, only occur on the local machine. The color model is the same system-wide and corresponds to the machine's display settings.

Windows uses a state-based model: drawing is done using Device Contexts (DCs) that retain state information about colors, fonts... in the form of so-called Objects such as brushes, pens... Feeding drawing parameters is done by selectings such objects into the DC. The subsequent primitives such as Rectangle() will use the currently available objects. DCs must be obtained before any drawing operation and must be released after. Objects must be created and destroyed manually.

The DC provides a full device-independance: it can be obtained from windows, printers, plotters... It uses logical integer coordinates but the mapping with physical coordinates (pixels, centimeters...) can be redefined. It also provides a capability-based system to query the features available on the devices, such as fonts, raster transfer, drawing primitives...

MacOS

(Note: my knowledge of MacOS is rather limited, please correct or complete the following statements)

Like Windows, MacOS QuickDraw uses a device-independent architecture. The display is local but can be spread on several monitors. The color model is the same for all the windows on a specific monitor, but can be changed on-the-fly by the user.

MacOs uses a notion similar to Windows' DC, the Graphics Port. It also uses a state-based model. At any time there is a current port available, named the World, on which the drawing primitives are called. To perform drawing on a specific port, one first have to select it as the World. Its drawing parameters can be altered by calling appropriate primitives to change drawing color, line width...

The Graphics Port is device-independent: it can refer to a window, a printer... (Note: I need information about coordinates systems).

TODO