TkGS Specification - Design Principles and Goals
The present document tries to specify TkGS according to several design
principles:
- Good cross-platform performance: TkGS should show good overall
performance on all system, without privileging one among others. In that
purpose, it must be designed to lower the global overhead on all supported
platforms, whatever they may be.
- Minimalism: TkGS should avoid using features not widely available across
platforms. On the other hand, it should cover most comon features, emulating
the missing ones if necessary.
- Portability: TkGS should be designed so that porting to a new platform
requires minimal effort.
- Extensibility: adding features to TkGS should be made easy without
breaking the whole architecture. Also, TkGs should be dynamically extensible
when possible (by the use of loadable extensions).
- Close to the existing models: TkGS should not be too far from existing
models (Xlib, Win32, QuickDraw) so that migrating existing applications
require minimal effort.
- Simplicity: TkGS should be simple to use. The above goals should not be
reached at the price of an increased complexity.
Some of these principles seem common sense but may have strong implications. Now
let us detail the goals of TkGS:
- TkGS is intended to completely replace the existing Xlib Emulation Layer
(XLEL) used by Tk. In that purpose, it should reuse as much existing code as
possible and avoid any modifications to other parts of the Tk core.
- TkGS will be made available as a separate extension during its design,
but will eventually be merged into the Tk core. The authors will retain
intellectual ownership on their code but use a licensing policy that is
compatible with Tk (as it is done with eg. Henry Spencer's regexp package).
- TkGS will be designed so that is creates a framework for printing
support. However it does not intend to provide any printing extension to Tk.
In that purpose, it should design an extensible device driver architecture
that will ensure access to virtually any graphics system available on the
supported system, ranging from PostScript output generation to DirectX and
OpenGL windows.
- All the existing Xlib code will eventually be replaced by TkGS. All the
Tk widgets' drawing code will be rewritten. In that purpose, TkGS should be
as close to Xlib as possible. The canvas widget being the most complex
widget with respect to graphics code, it should be rewritten in priority. A
temporary Xlib emulation layer on top of TkGS could be written to preserve
compatibility with older code.
- The first TkGS driver will be build on top of the existing Xlib code, as
a proof of concept (TkGS being a wrapper at this stage). A native Win32
driver will follow shortly and help confirm and refine the model.
- 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).