Display Driver Performance

The following three major factors affect the graphics performance of your platform:

  • The usage scenario for your device.
  • The graphics hardware on your device.
  • The design of your driver code.

Assuming that your hardware design is fixed and the usage scenarios for your device cannot be changed, the challenge is then to find ways to improve your driver's code.

Before you take steps to improve your driver's performance, you should first get an objective measure what its current performance really is. The DispPerf tool can be used to create a performance profile for your platform's display system. For the best profiling results, run DispPerf on a retail build of your platform while running a graphically intensive scenario for your device. For more information about DispPerf, see Display Driver Performance Profiling.

When an application sends a graphics command to the operating system (OS), the OS processes the high-level command into more discrete graphics operations, which are then sent down to the display driver. When the display driver receives these operations, it attempts to find the most efficient way to render them. First, the driver checks to see if the operation is supported directly by the graphics hardware. If not, then the driver tries to find a function among the BitBlT emulation library functions to handle the operation. If this is also unsuccessful, then the driver defaults to using one of the standard Graphics Primitive Engine (GPE) functions.

You can analyze the output from DispPerf to see which functions are being called within your driver and where the most time is spent. Look for any use of the EmultedBlt family of functions. These functions indicate that your driver is using software-based rendering in its code path rather than hardware-based rendering. The first and best step toward optimizing your driver's performance is to try to convert such operations to hardware-based operations if at all possible. For details, see Bit Block Transfers and Line Drawing Acceleration.

If your hardware does not support the operations that you would need to replace an emulated graphics operation, then your next best option is to write your own emulation function to perform the graphics operation you need, or to optimize one of the existing ones to better fit your specific hardware and scenario. This allows you to take advantage any specialized knowledge you have about your device or scenario, rather than the relying on the generalized emulation functions exported by Emul.lib. The source code for Emul.lib is located in the %_WINCEROOT%\Public\Common\OAK\Drivers\Display\Emul directory.

When reviewing the results from DispPerf, also look for any functions that inherently use large amounts of CPU time, such as WaitForNotBusy. For more information, see How to Profile and Optimize a Display Driver.

See Also

Display Drivers | Display Driver Samples | Device Driver How-to Topics | Device Drivers | BitBlT Emulation Library Functions

 Last updated on Tuesday, May 18, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.