You can regard the Display PostScript system as part of the X Window System. Your application will use X Window System features for window placement and sizing, menu creation, and event handling, while using Display PostScript system features to take care of imaging inside the window.

Display PostScript system components include the Client Library, the PostScript interpreter, and the pswrap translator.

The Digital UNIX documentation set includes the Developing Applications for the Display PostScript System.

• Associate multiple image buffers with a window

• Paint in any image buffer associated with a window

• Display a series of image buffers in a window in rapid succession to achieve smooth animation

• Request simultaneous display of different image buffers in different windows

To the programmer, OpenGL is a set of commands that allows the specification of geometric objects in two or three dimensions, together with commands that control how these objects are rendered into the frame buffer. For the most part, OpenGL provides an immediate-mode interface, so that specifying an object causes it to be drawn.

A typical program that uses OpenGL begins with calls to open a window in the frame buffer into which the program will draw. Then, calls are made to allocate a GL context and associate it with the window. Once a GL context is allocated, the programmer can issue OpenGL commands. Some commands are used to draw simple geometric objects for example, points, line segments, and polygons. Other commands affect the rendering of these primitives, including how they are lit or colored and how they are mapped from the user's two- or three-dimensional model space to the two-dimensional screen. OpenGL also has commands that affect direct control of the frame buffer, such as those that read and write pixels.

In the X Window System, OpenGL rendering is made available as an extension to X in the formal X sense: connection and authentication are accomplished with the normal X mechanisms. As with other X extensions, there is a defined network protocol for the OpenGL rendering commands that are encapsulated within the X byte stream.

Information on OpenGL is provided in the OpenGL Reference Manual.

The protocol version of PEX supported for Digital UNIX is PEX 5.1, which is available only through the DEC Open3D kit.

All requests are passed to the server by means of a shared memory queue. The server and client control the flow by using X protocol requests over UNIX Domain sockets. All events, replies, and errors are returned through UNIX Domain sockets.

This transport is suitable only for high-bandwidth applications that typically use large requests. Short requests may take longer to process with SMT than with UNIX Domain sockets because of synchronization overhead. For example, XNoOp requests will take twice as much time to execute.

The DISPLAY environment variable must be set to local:0 when SMT is used.

When using SMT, the X server may not be able to allocate a shared memory segment. This problem occurs if the system shared memory resources are depleted; a warning message appears on the client side.

With this extension, clients on different hosts running different operating systems can be synchronized. Multimedia applications can use this extension to synchronize audio, video, and graphics data streams. In addition, the extension provides internal timers within the X server that can be used to synchronize client requests. Using this feature, simple animation applications can be implemented without having to use round-trip requests. The extension allows applications to make the best use of buffering within the client, server, and network.

The X Consortium provides documentation for XIE in PostScript format. That documentation is located on the Digital UNIX system in the /usr/doc/xie directory. The following list describes the documents:

• X Image Extension Overview

  This document provides general information about the X Image Extension code. Topics covered are: XIE design goals, XIE historical summary, XIE architecture, element definitions, and subsetting.

• XIElib Specification

  This document contains reference descriptions of all the XIElib functions, XIElib events, and XIElib errors. The Functions section covers the following types of functions: startup, LUT, photomap, ROI, photoflo, client data, abort and await, photoflo element, technique, and free.

• XIE Sample Implementation Architecture

  This document is for X Consortium members who have a working understanding of the X Imaging Extension. It provides an architecture overview as well as chapters on the following topics: extension initialization, memory management, request dispatching, data representation, data structures, protocol requests, DIXIE photoflo management, DDXIE photoflo management, and photo elements.

• X Image Extension Protocol Reference Manual, Version 5.0

  This document specifies the X wire protocol for the X Image Extension. It defines the syntax, structure, and semantics of the XIE protocol elements. Topics covered include syntax specification, parameter types, resources, pipelined processing, import elements, process elements, export elements, events and errors, techniques, service class, and protocol encodings.

• Support for the ISO9996 standard for keyboard layouts

• Compatibility with the core X keyboard handling (no client modifications are required).

• Standard methods for handling keyboard LEDs and locking modifiers such as CapsLock and NumLock

• Support for keyboard geometry

The function of the mode switch is similar to that of the Shift or Shift Lock key. These mechanisms both enable multiple symbols (keysym) to be generated from single keys, with one symbol for one mode or shift or shift-lock state and another symbol for the other state. For example, on the American keyboard, 3 and # can be switched by the shift state.

The combination of the mode-switch and shift/lock mechanisms allows up to four keysyms to be established for a single key.

The entry point XKMEDoKBModeSwitch is defined for the mode-switch modifier and can be set to the following modes of operation:

The dxkeycaps(1X) reference page describes how to access the shift modifier from client applications and contains general information on keyboard mappings.

• Minimize portability problems by confining the extension to an appropriate high level within the X server. In practice, this goal means that the extension should be at the DIX level, use the DIX/DDX interface, or both. This specification has effects, in particular, on the level at which input synthesis can occur.

• Minimize the changes required in the rest of the X server.

• Minimize the performance penalties that running the test produces on normal X server operation.

• Lists available video adapters

• Identifies the number of ports each adapter supports

• Describes what drawable formats each adapter supports

• Describes what video encodings each adapter supports

• Displays video from a port to a drawable format

• Captures video from a drawable format to a port

• Reserves ports for exclusive use and unreserves them

• Sets and gets port attributes

• Delivers event notification

Until recently, the data type used with a format of 32 was implied, not specified. With the new refinements, the data that is provided in format 32 to the XChangeProperty function or returned from the GetWindowProperty function should be accessed as arrays of longwords or typedefs based on longwords such as Window or Atom.

Specify either the -ldnet_stub or -ldnet flag when:

• using the cc -non_shared command

• using the ld -non_shared command

• linking against the libX11.a static library

If you link your X client application to the nonshared version of the /usr/lib/libDXm.a library, you must include libbkr in the link line. If you omit libbkr, the warning messages appear about the following undefined symbols:

DXmHelpSystemClose
DXmHelpSystemDisplay
DXmHelpSystemOpen

The loadable X server, as well as clients and libraries that directly execute calls to DECnet functions, are built using the libdnet_stub.so shared library in the ld command that links the object files. DECnet functions that are commonly called include getnodename, dnet_addr, and dnet_conn.

X clients that are built fully static and include libX11.a or libXmu.a must incorporate the libdnet_stub.a library if they do not use the DECnet transport. If they do use the DECnet transport, they must incorporate the libdnet.a library. One of these libdnet libraries must be included to resolve function calls from within the libX11 or libXmu modules. If the X client is not fully static, but is using libX11.a or libXmu.a for some other reason, libdnet_stub.so should be included in the ld command information so that the client can be used whether or not DECnet is installed.

Note that DECnet/OSI is not part of the Digital UNIX operating system.

There are two functions in the Display PostScript language that correct this problem: