PDRREF:Design Considerations for Display Drivers

When an application requires a user to choose an object from a presentation space, the user typically selects the object by positioning the mouse cursor over the object and clicking the mouse buttons. This action sends a message to the application, informing the program of the current (X,Y) position of the mouse cursor. However, it is still up to the application to determine the object selected. This is accomplished by the application defining a rectangular area called the "pick aperture," which is centered on the reported mouse position, and determining which, if any, of the currently defined segments intersect or lie completely within the pick aperture. The process of determining intersection or inclusion within the pick aperture is called "correlation."

Naming Conventions
Because some 16-bit hardcopy drivers load a 16-bit DISPLAY.DLL and call it directly, OS/2 includes a 16-bit DISPLAY.DLL, which provides the necessary functions for these hardcopy drivers. Therefore, all 32-bit display drivers must have new and unique names.

Correlation
Correlation must be performed by all display drivers in page coordinates on fully clipped primitives. (Correlation is not required for hardcopy devices.) Correlating on areas is particularly complex because GreSetCurrentPosition and GreEndArea generate a closure line when the current position is not at the start of the current closed figure. This closure line can cause a correlation hit. Also, the area interior, itself, can cause a correlation hit that must be reported on the GreEndArea order.

The lines (arcs, full arcs, boxes, and fillets) defining the area boundary can cause a correlation hit if the area is specified with boundary. This hit must be reported when the function is issued.

Correlation and Retained Segments
To be a candidate for correlation, a retained segment must: Each primitive or group of primitives within a given segment must be capable of maintaining tag information. Tag information is added to an object in response to an application calling GpiSetTag. The pick tag is a positive integer. If 0 is specified as the pick tag, detectability should be turned OFF for subsequent primitives. The pick tag is 0 by default. The tag specified in the most recent call to GpiSetTag is the current tag, and remains in effect for all subsequent drawing operations until another call to GpiSetTag is made. The tag is considered to be a part of the current attributes for the segment and, therefore, is affected by the current attribute mode of the segment.
 * Have a unique identifier
 * Be a nondynamic object
 * Be defined as detectable (see following explanation)

An application can request correlation data for: The presentation driver returns the names of segments within the pick aperture in reverse order of their occurrence on the segment chain. This data is returned in the form of segment and tag pairs. Each unique segment and tag pair within the pick aperture is termed a correlation hit. If two or more primitives within the current pick aperture have the same tag, they are considered as a single correlation hit. When a called segment is picked, correlation data is also returned for all segments above it in the hierarchy (up to and including the root segment). This also constitutes a single correlation hit.
 * Segments that have been defined as both detectable and visible
 * All nonzero segments that intersect the pick aperture regardless of the object detectability and visibility attributes

Correlation and Nonretained Segments
Nonretained graphics are those objects that are correlated on during the drawing process. If nonretained objects are to be correlated on, they must have unique identifiers and be defined as detectable. The application must set the correlate bit of the Draw Control flag passed to the engine from the function GpiSetDrawControl.

Drawing to Display Devices
Because changes on the screen can affect more than one device context, the graphics engine notifies the display driver when a change occurs. Notification is performed through a call to the function (see GreDeviceInvalidateVisRegion) in the display driver. This routine identifies the affected device contexts and supplies a pointer (pInstance) to the instance data of each device context. The handling routine for GreInvalidateVisRegion sets a flag, such as HDC_IS_DIRTY, in the instance data for all identified device contexts.

All routines that draw to the screen test the HDC_IS_DIRTY flag. If this flag is set, the routines call VisRegionNotify before drawing the visible region.

Distributed Console Access Facility (DCAF)
The IBM Distributed Console Access Facility (DCAF) provides remote console capability via communication links. DCAF allows one programmable workstation to act as a controlling workstation. From this workstation the user can control and monitor the display output of another programmable workstation, called a target workstation.

Operating States
DCAF has two operating states: monitoring and active.
 * Monitoring State: When a DCAF session is in this state, the controlling workstation displays an image of the target workstation's display. The target workstation user, however, retains complete control of operations on the target workstation.
 * Active State: When a DCAF session is in this state, the user of the controlling workstation, referred to as the controller, operates and controls the target workstation. Any keystrokes typed by the controller, and the resulting screen image, are displayed on the target workstation, just as if the target user had typed the keystrokes directly. As in the monitoring state, the controller sees an image of the target workstation's display. In the active state, keystroke input from the target workstation is not accepted. However, if the hot key combination is enabled for the target workstation, the target user can use the key combination to regain control of the workstation and change the session state.

Concurrent sessions can be established on multiple target workstations by a single controlling workstation. On the other hand, a target workstation can be connected to only one controlling workstation session at a time, even though multiple controlling workstations can be defined within the network.

For more information about DCAF, see Distributed Console Access Facility (DCAF) Architecture in Display Drivers, as well as the individual functions in Mandatory and Simulated Graphics Engine Function Reference.

Direct Interface Video Extensions (DIVE)
The first implementation of Graphics Driver interfaces for high speed access to graphics hardware were shipped in the OS/2 2.1 DDK as extensions or DEVESC_ functions. The DEVESC_GETAPERTURE, DEVESC_ACQUIREFB, DEVESC_SWITCHBANK and DEVESC_DEAQUIREFB functions provide a device independent interface for application and system software to access display memory directly. With these DEVESC_ functions, time-sensitive software requiring simple, fast graphics throughput achieves a sizable performance boost.

Using the DIVE architecture, the OS/2 multimedia subsystem writes directly to video memory. As a user of the DIVE driver functions, the subsystem performs all window clipping, color translation and scaling required to write the data correctly in a window. Additionally, on bank-switched configurations, software using the DIVE driver functions must detect when video memory bank boundaries are crossed and then switch the bank correctly.

Enhanced Direct Interface Video Extensions (EnDIVE)
In OS/2 Version 3, the DIVE driver architecture has been enhanced to support the use of motion video accelerator hardware. This enhanced DIVE architecture is called EnDIVE. It provides additional DEVESC_ functions for querying information about the color formats supported by the hardware, video memory managment and image processing.

When the hardware is present in the graphics system, OS/2 display drivers look for and load a "buddy" DLL that supports the EnDIVE functions. In turn, software using DIVE architecture drivers will detect and use the additional functions to accelerate image processing operations.

OS/2 Version 3 DIVE Display Engine
The DIVE Display Engine simplifies the complexities of dealing with the DIVE and EnDIVE driver functions. As a single, system-level API, the Display Engine enables efficient transfer of data to video memory with clipping, scaling and color translation. The Display Engine also abstracts the DIVE and EnDIVE driver interfaces to a higher level.

Using the DIVE Display Engine, applications can either write directly to video memory or use the DIVE blitter to get a high level of screen update performance, image scaling, color translation and bank-switch display support. The DIVE Display Engine also detects and uses acceleration hardware (via EnDIVE) and substitutes software algorithms whenever necessary. In this way, the DIVE Display Engine abstracts the low-level DIVE and EnDIVE driver interfaces to a higher level, adding software emulation for operations that each DIVE driver user has to do.