TkGS Specification - Design Principles and Goals

The present document tries to specify TkGS according to several design principles:

Some of these principles seem common sense but may have strong implications. Now let us detail the goals of TkGS:

Implications

Graphics model
We have seen that the first cause for the bad performances of the XLEL is its stateless model that introduces a huge overhead on state-based models such as Windows and MacOS. However building a state-based model on top of a stateless model does not induce the same problems, the only overhead being the extra memory consumption needed to retain state, which is quite modest and unavoidable anyway. TkGS will then use a state-based model.
Device independence
Windows and MacOS use device-independent graphics operations, allowing easy printer support. Xlib limits to display devices. TkGS should then retain native device-independence whenever available and design a driver architecture to provide device-independance on all platforms. Xlib will be seen as a display device, the same way PostScript will be seen as a printer device. TkGS will allow a transparent access to all devices.
Extensibility
Due to the extensible nature of TkGS, it should provide a capability-based architecture, allowing applications to query the features available on the different devices.
Cross-platform support
TkGS will provide all the commonly available graphics primitives and operations, and will try to emulate the missing ones whenever possible. When a good compromise between native and emulated feature support cannot be found, it will be limited to the commonly available features. For example, a rare but useful drawing primitive (eg. rounded rectangle) will be easily emulated using other primitives, whereas support for a feature where differences between platforms are too important (eg. clipping) will be limited to the most useable/used subfeatures (rectangular clipping), giving up the too different ones (arbitray shaped clipping).