PDRREF:Design Considerations for Display Drivers

From EDM2
Jump to: navigation, search
Presentation Device Driver Reference for OS/2
  1. Introduction to OS/2 Presentation Drivers
  2. Design Considerations for All Drivers
  3. Graphics Engine/Presentation Driver Design Changes
  4. Design Considerations for Display Drivers
  5. Design Considerations for Hardcopy Drivers
  6. Display Drivers
  7. Distributed Console Access Facility (DCAF) Architecture
  8. Graphics Engine Hardcopy Drivers
  9. Queue Drivers
  10. Port Drivers
  11. Presentation Manager Function Categories
  12. Exported Driver Function Reference
  13. Mandatory and Simulated Graphics Engine Function Reference
  14. Device Support Function Reference
  15. DBIDI Command Structures and Command Flow

Appendixes

A - OS/2 Version Compatibility Considerations
B - Syntax Conventions
C - Format of the Journal File
D - Bit-Map Simulation for 16-Bit Hardcopy Drivers
E - Data Types
F - Notices

Miscellaneous

G - Glossary

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

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:

  • Have a unique identifier
  • Be a nondynamic object
  • Be defined as detectable (see following explanation)

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.

An application can request correlation data for:

  • 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

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.

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.

PDRREF-005.png