Display Driver Performance (Windows Embedded CE 6.0)
1/6/2010
The following 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, get an objective measure what its current performance is. You can use the DispPerf tool to create a performance profile for your platform's display system.
For the best profiling results, run DispPerf on a release build of your run-time image 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 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 the operation is not supported directly by the graphics hardware, the driver tries to find a function among the BitBlT emulation library functions to handle the operation.
If this is also unsuccessful, 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 you need to replace an emulated graphics operation, write your own emulation function to perform the graphics operation, or optimize an existing function to fit your specific hardware and scenario.
This allows you to take advantage of specialized knowledge you have about your device or scenario, rather than relying on the generalized emulation functions exported by Emul.lib.
The source code for Emul.lib is in the %_WINCEROOT%\Public\Common\OAK\Drivers\Display\Emul directory.
When reviewing the results from DispPerf, also look for functions that inherently use large amounts of CPU time, such as WaitForNotBusy.**
See Also
Reference
BitBlT Emulation Library Functions
Concepts
Display Driver Development Concepts
Display Driver Samples