The following existing functions will be simulated by the graphics engine:
If the current presentation driver's dispatch table has not hooked out this function, the graphics engine will handle the PolyScanLine call. The graphics engine will convert the shortline structure to a set of rectangles and pass them as ROP_PATCOPY BITBLTS to the presentation driver.
The graphics engine will convert the PLINE structure (which is passed into the DrawLinesInPath function) into the LINEINFO structure required by the SDLine function.
The device will now give the capabilities to the graphics engine during the OS2_PM_DRV_ENABLE: QueryDeviceSurface call. The graphics engine will then do the default handling on the information provided earlier. The presentation driver can dynamically change its device capabilities through the GreSetDeviceSurface call.
The graphics engine will create and manage bit maps if the presentation driver has not hooked the following bit map functions:
Bitblt is fully supported. Presentation drivers need not hook this function or call back for simulation. Bit maps could be stretched, flipped, rotated and sheared. The engine will do the simulation and call Bitblt with COM_DEVICE set (if the Bitblt is hooked) or call SDBitBlt. If SDBitBlt is called, the bits are preclipped. Stretching (not rotation or shear) will be done in batches.
The graphics engine converts this call to a BitBlt call with a 1x1x[dst bpp] source bit map. It will behave as described in the OS/2 Presentation Device Driver Reference, Fourth Edition.
The graphics engine converts this call to a BitBlt call with a 1x1x[dst bpp] destination bit map. It will behave as described in the OS/2 Presentation Device Driver Reference, Fourth Edition.
CharString will be handled by retrieving the current position and calling the Device Driver Interface (DDI) CharStringPos.
CharStringPos simulation will start by handling the current default requirements of the Device Driver Interface. That is, the string is being output in the left/right direction and supports a raster image of the current font. All simulation currently being handled by the engine will still take place; then on the CharStringPos call with the COM_DEVICE flag set, the default handling will take place.
PolyMarker simulation will be handled by using the default ATM scalable marker that is currently provided for hardcopy drivers. This simulation will give the display marker the ability to support attributes and different sizes with the default marker.
The engine now stores the code page in the engine's device context. The code page will be provided by the engine if requested by the driver.
The engine currently stores the device origin in device coordinates on a device context basis. For simulation, the engine will return these values.
This is still a mandatory function. The driver is now required to pass through the DevEscape function to the graphic engine's DevEscape entry point for certain DevEscape simulation (QueryVIOCellSizes).
Attributes are already stored by the engine. Now the engine will return only the correct values in the case of DeviceGetAttributes, and set either the appropriate dirty flags or physical attributes in the case of DeviceSetAttributes and DeviceSetGlobalAttribute.
The following functions do not require graphics engine simulation, and will simply provide the appropriate return code: