|
As the name implies, DPS uses the PostScript imaging model and language to generate on-screen graphics. In order to support interactive, on-screen use with reasonable performance, a few changes were needed:
*''multiple [[execution context]]scontexts'': unlike a printer setting where the PS interpreter had only one job at a time, DPS would be used in a number of [[window]]s at the same time, each with their own settings ([[color]]scolors, [[brush]] settings, [[scale]], etc.). This required a modification to the system to allow it to keep several "[[context]]scontexts" (sets of state data) active, one for each process (window).
*''[[encoded name]]snames'': many of the procedures and data structures in PostScript are looked up by name. In DPS these names could be replaced by small numbers, which are much faster for a computer to find.
*''[[interaction]] support'': a number of procedures were defined to handle interaction, including [[hit detection]]
*''halftone phase'': in order to improve scrolling performance, DPS only drew the small portion of the window that became visible, shifting the rest of the image instead of re-drawing it. However this meant that the [[halftone]]s would not line up, producing visible lines and boxes in the display of graphics. DPS included additional code to properly handle these cases. Modern full-color displays with no halftones have made this idea mostly obsolete.
*''[[incremental update]]updates'': in printing applications the PS code is interpreted until it gets a <code>showpage</code> at which point it is actually printed out. This is not suitable for a display situtuation where you need a large number of minor updates all the time. DPS included modes to allow semi-realtime display as the instructions were received from the user programs.
*''[[bitmap font]] support'': DPS added the ability to map PS fonts onto hand-drawn [[bitmap fontsfont]]s and change from one to the other on the fly. While PS's ability to display fonts on "low rez" devices was good, "low rez" meant something on the order of 300dpi, not the 96dpi that a NeXT screen used. This required hand-built fonts for reasonable output.
*''[[programming language]] support'': DPS introduced the concept of a "[[pswrap]]", which allowed [[developer]]s to wrap PostScript code into a [[C programming language|C language]] function which could then be called from an application.
DPS did not, however, add a windowing system. That was left to the implementation to provide, and DPS was meant to be used in conjunction with an existing windowing engine. This was often the [[X Window System]], and in this form Display PostScript was later adopted by companies such as [[International Business Machines|IBM]] and [[Silicon Graphics|SGI]] for their workstations. Often the code needed to get from an X window to a DPS context was much more complicated than the entire rest of the DPS interface. This greatly limited the popularity of DPS when any alternative was available.
| 