Screen Driver Graphics Acceleration Support

This topic introduces the 2D graphics hardware acceleration support provided by the Screen Driver component. This is generally used only in the non-ScreenPlay variant, because ScreenPlay provides better alternatives for implementing support for graphics acceleration hardware.

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.