Screen +Driver Graphics Acceleration Support

Variant: Non-ScreenPlay. Target +audience: Device creators

2D graphics acceleration enables improved performance for multimedia applications. +The Screen Driver component provides an API for hardware acceleration. This +is defined in graphicsaccelerator.h and is abstract. +The abstract base class for all accelerators is CGraphicsAccelerator. +The API also defines a set of common 2D graphics operations that are capable +of being accelerated in hardware (by a separate graphics processor), or in +software (by a DLL that optimizes the algorithms for particular devices and +display modes). The API may or may not be implemented by device creators.

Note that graphics acceleration, if implemented in the Screen Driver component, +is designed to be used transparently within BitGDI, +not called explicitly by clients.

Architectural relationships

The Screen Driver API +for 2D graphics hardware acceleration is closely related to the following:

GDI. +The graphics acceleration support that is provided by the Screen Driver component +is integrated into the underlying implementation of the GDI API. Applications +do not need to be aware of whether or not a particular graphics operation +is accelerated. If an accelerated implementation of a function is available, +it is used in preference to the generic algorithm.
BitGDI. +Software graphics accelerators can draw to standard bitmaps (the CFbsBitmap class), +as well as hardware bitmaps (represented by the RHardwareBitmap class). +However, hardware graphics accelerators can only draw to hardware bitmaps.

Description

Each class derived from TGraphicsOperation represents +a different accelerated graphics operation. The subset of these operations +supported by an accelerator is hardware-dependent and varies from device to +device. The graphics accelerator's capabilities can be queried before it is +used. The TGraphicsAcceleratorCaps class gives some of +the capabilities, for instance whether mask bitmaps must be in a certain display +mode. To find out whether a particular operation is supported, an attempt +should be made to execute it. Unsupported functions should simply return KErrNotSupported. +The user of the API does not need to be aware of whether an operation is accelerated +in hardware or in software—the API is the same for both.

The types +of accelerated operations that are enabled by this API include:

filling a rectangle +with a color or pattern; fading and inverting colors
a variety of bitblt +operations, including using a mask, transparency or alpha blending. These +operations may involve scaling the bitmap
filling a polygon with +a color or a pattern.

All of these operations may optionally take place within a clipping +region.

Hardware graphics acceleration can only draw to hardware bitmaps. +These are bitmaps that are stored in a static, contiguous area of physical +memory that is accessible to both the CPU and a separate graphics processor. +The interface to a hardware bitmap is the class RHardwareBitmap. +Software graphics acceleration can write to both CFbsBitmap s +and RHardwareBitmap s.

Limitations

The Screen Driver provides a synchronous +API for the implementation of hardware acceleration. This means that although +each operation may execute faster than within a software implementation, the +calling thread on the CPU must wait for each GPU operation to complete. This +can cause significant delay within the context of the Window Server. In addition, +graphics acceleration hardware is generally designed to accept a pipeline +of instructions rather than the individual instructions provided by the Screen +Driver. The Screen Driver's one-by-one approach causes greater latency than +could be achieved using a pipeline approach. These limitations are part of +the rationale for the introduction of the ScreenPlay +architecture.