One of the new features introduced by GKS was the concept of a Logical Workstation. This provides an interface layer within the graphics package below which are situated a set of workstation drivers. The workstations simulate in software any features which are not provided by a particular display, and so simplify the problem of driving new devices. To the applications programmer all workstations have (more-or-less) similar capabilities, although their response time will clearly be faster if these capabilities are built into the hardware, rather than emulated. However, GKS defines only the interface as seen by the application, and not the internal workstation interface. This means that it is not possible to move workstation drivers from one implementation of GKS to another.
There are difficulties in defining this interface because, if the level is too high, then most workstation drivers must incorporate a great deal of code. If on the other hand the level is too low, then the software will not be able to make use of advanced features in high-performance display systems. There is thus is a trade-off to be made, which is currently decided upon by the designers of each graphics package. The goal of the CGI [8] is to standardize this interface. However, it is proving to be a lengthy business, because there are difficulties to persuade all the parties involved to compromise.
It should be mentioned that one of the goals of CGI is to allow the functionality of the graphics system to be split between multiple CPUs. For example, the features defined by the CGI could either be built into a graphics terminal, or programmed into a Personal Workstation. This type of functionality has become loosely termed Networked Graphics.
In this realm CGI may be overtaken by events, because a networked graphics
system called X-Window is fast becoming a 'de facto' standard.
X-Window comes from MIT, and is an outcome of the Athena Project
financed by DEC and IBM.