|
Introduction to Writing Windows CE Display Drivers(5)
If your display device is VGA based, you may choose to derive your device class from the GPEVGA class rather than GPE. GPEVGA is itself derived from GPE, and is still pure virtual. It contains function implementations for SetPalette() and InVBlank(), using standard VGA accesses. It also contains I/O mappings to standard VGA registers. Beyond this, you will still need to implement the remaining functionality required in the GPE base class.
There is a variation of the GPE based driver, called a dirty rectangle driver. Its purpose is to allow a display driver based on the GPE class to work with a banked memory display device. An example of this is the sample driver VGA8BPP. It is a very inefficient driver from both a system resource and performance standpoint and should really only be used if a linear frame buffer is not available. It works by creating a frame buffer in system memory that is the size of the display. This is very inefficient from a system memory standpoint since memory is usually a critical resource in a Windows CE device. All drawing by the GPE default drawing functions is done into this system memory frame buffer. These areas where drawing is done, or dirty rectangles, are then copied to the display memory on a bank by bank basis. The inefficiency here, of having to do the drawing in two steps, is obvious.
Another important class is GPESurf, which is used to represent surfaces located in system memory. If the driver supports the creation of surfaces in video memory, then the GPESurf class will need to be derived from. However, these changes are fairly minor and mostly require capturing of the Node2D information, mentioned later, and setting the flag to indicate that this surface is located in video memory.
The last class I'm going to mention is Node2D. This class is used for managing video memory surfaces. An instance of a Node2D object is initially created that contains the pixel dimensions of the total video memory. Allocation of video memory for surfaces, including the primary display surface, is then handled through this Node2D instance. Within the class itself, the video memory is managed as a list of free and allocated rectangles, with all coordinates handled in pixel dimensions. The limitations of this class are that video memory surfaces cannot be created that are wider than the pixel dimensions supplied when the instance of the class was created and that video memory surfaces must be the same color depth as the display.
|
