TkGS (the Tk Graphics System) is a cross-platform graphics system for the Tk Toolkit that is intended to replace the current XLib emulation layer implemented in the Win32 and MacOS versions of Tk.
TkGS is intended to be a low-level cross-platform API to leverage GUI differences, the same way the Tcl API leverages OS differences. It is not intended to be a high-level drawing system.
Although specified using the C programming language, TkGS is not a library but a specification. There will eventually be a reference implementation as a proof of concept.
This document mainly describes the philosophy of TkGS. It also tries to define some structures and functions. It is intended to serve as a basis for a wider discussion.
First, let us explain why TkGS is a low-level API and not a high-level graphics library. Most users agree that the power of Tk is unleashed at scripting-level, and that this is why Tk is mainly used in conjunction with high-level scripting languages (Tcl, Perl, Python...) rather than with C through its APIs. From the scripting perspective, Tk already provides very high level drawing systems such as the canvas widget. However, Tk C APIs are rather low-level: they are based on the X library (Xlib) which is natively available on Unix systems and emulated on Windows and MacOS systems through the Xlib Emulation Layer (XLEL).
Second, let us talk about the Xlib Emulation Layer and why it needs to be replaced by something more adapted, something TkGS tries to be. Older versions of Tk (up to Tk 3.6) were only designed for the X-Window system. Tk was designed as a higher-level layer on top of the Xlib. Tk applications then naturally used the Xlib as a graphics subsystem for low-level graphics operations. Starting from version 4.0, Tk began to be a cross-platform GUI system, as the authors began to work on native versions for Windows and MacOS. In the purpose of easing the porting of Tk and other extensions, they decided to port a part of the Xlib to the newly supported systems. The Xlib Emulation Layer was born. This allowed a fast porting of existing code to the new platform without the need for (much) rewrite.
But first versions of Tk had the Motif-like look&feel on all platforms. Tk version 8.0 introduced better native support for Windows and MacOS platforms: Tk applications started to look like native applications. This introduced many changes in the Tk APIs: new higher level functions and structures appeared to mask OS differences for elements like fonts, thus replacing the related Xlib emulation procedures, making Tk a bit faster and more GUI-neutral. But most of the Xlib procedures did not need to be replaced, as they worked fine, and so the XLEL continued its life.
So what is the problem with the XLEL? Porting part of the Xlib to new platforms was a good idea in the beginning because it allowed for easier porting of the many existent Tk applications. The counterpart is that one had to use the Xlib graphics model on all platforms to remain portable, and that is the main cause of the XLEL inadequacy: bad performances. Tk is notably slower on platforms other than native X-Window systems. But this lack of performance is not due to the XLEL itself, but to the way it uses the native graphics system. The Xlib uses a fundamentally stateless model, whereas Windows and MacOS use state-based models.
For example, to draw a shape, a Xlib application calls a drawing primitive such as XDrawRectangle() and passes the drawing parameters as arguments in the form of a Graphics Context (GC), a structure that contains all the drawing parameters such as foreground color or font. On Windows, one has first to create objects such as brushes, pens, fonts, then select these objets that will be used by all the subsequent primitives such as Rectangle(). These objects are selected into a Device Context (DC) that has to be created before any drawing and released after, holding the state in the meantime. These operations are costy and thus should be done once for all before any primitive is called. Besides, since they are available in rather limited resources, one has to be careful to free them all once the drawing operation is complete.
Since The Xlib uses a stateless model, the XLEL has no choice but to re-create a valid drawing context (eg. a DC on Windows) from its GC values at every drawing operation. That way, costy operations that were intended to be called once before any number of drawing primitives (ie in O(1) time), are called for every primitive (ie in O(n) time), even if the drawing parameters are the same. Thus the relatively bad performances of Windows and MacOS Tk (even on the same hardware). A solution would be to use caching schemes to avoid useless re-creation of drawing structures. Leo Schubert's speedpatch for Tk 8.0 uses this kind of technique (it stores the internal GDI objects into the GC structure). Although the results are impressive in term of performances, these techniques have several drawbacks:
TkGS tries to address the issues raised by the XLEL. In particular, it defines a state-based model to eliminate the performance problems. Actually, implementing a stateless model on top of a state-based model is much costy than the contrary in term of performances. TkGS also tries to enlarge the cross-platform availability of Tk: unlike Xlib which is a (rater) frozen API, TkGS can evolve depending on the problems it encounters when, for example, porting natively to a new platform (BeOS, OS/2, Amiga...). TkGS also tries to address the long-awaited printing issue by providing a device-independent system that makes the kind of graphics device (display, printer) transparent from an API perspective, the way it is already available on Windows and MacOS. X-Window only handles display devices, and printing has been traditionally done via PostScript printers on Unix systems. This is the reason why the only printing features available in Tk are the canvas PostScript output. Enabling printer access at a lower level would print-enable the whole Tk on any platform. Finally, TkGS tries to define an extensible architecture that would, for example, allow the use of DirectX and OpenGL output, or - why not - remote display from any non-X-hosted Tk application to a real X server through the use of a native Xlib client library.