Article ID: 247058 - View products that this article applies to.
This article was previously published under Q247058
Original equipment manufacturers (OEMs) should pay particular attention to graphics performance. Some customers do not implement software-accelerated graphics functions that can improve performance. Incorporating these functions may reduce read-only memory (ROM) by as much as of 10 KB. However, the benefits, which include snappy screen painting and the overall appearance of faster performance, outweigh the problems.
Adaptation kits come with a generic graphics emulation (GPE) library that supports all bit depths from 1 to 32 bits per pixel (BPP), and therefore are not optimized for any particular display. The performance for your particular display probably is suboptimal if you rely solely on this library. Significant performance gains can be achieved by replacing frequently used functions in the GPE library with your own optimized emulation functions. Microsoft provides sample code for 2 BPP, 8 BPP, and 16 BPP optimized emulation functions.
Please refer to the following sections for more details on how to improve the performance of your video driver:
Supporting Bit Block Transfers in Windows CE Display DriversBeginning with Windows CE 2.0, a display driver can make use of up to three levels of BLT processing:
The following sections briefly introduce the GPE and emulation software libraries. Sample source code from the Embedded Toolkit (ETK) demonstrates how to choose the desired method of BLT processing in the display driver. Build environment directives may be used to control the inclusion of code for accelerations. These directives are introduced along with an explanation of how to include the GPE and emulation libraries in the Windows CE operating system image. The functions of the emulation library are listed along with their associated ROPs, as well as source and destination pixel depths.
The GPE Library for Default BLT ProcessingGPE is the Graphics Primitive Engine class library. In the Embedded Toolkit, the library is provided in binary form and may be found in the Public\Common\Oak\Lib folder. The class library serves as the basis for Windows CE display drivers. GPE provides default processing for BLTs in its EmulatedBlt function.
The Emulation Library for Software-Accelerated BLTsWindows CE provides an emulation library (as sample code) for software-accelerated BLTs. In the Embedded Toolkit, the library can be found in the Public\Common\Oak\Drivers\Display\Emul folder. The library contains emulated BLT functions for BLTs at various destination pixel depths, including 2, 8, and 16. The emulated BLTs can be used to improve performance over and above the default BLT processing that is provided in GPE. The embedded developer can use this source code as a template for writing more software-accelerated BLTs, as appropriate for the target hardware and software.
Handling BLTs and Accelerations in a Display DriverIn a Windows CE display driver, the driver routes BLT handling to either GPE (the default), the emulation library, or directly to the hardware. The S3Trio64 display driver demonstrates how all three of these methods are invoked. The sample code that is included here can also be found in the Embedded Toolkit in the Platform\Cepc\Drivers\Display\S3trio64 folder. BLT processing begins with a call to the driver's BltPrepare function. It initializes the BLT parameters and determines which function will be used to perform the individual BLTs. Typically, GPE is initialized to handle default BLT processing.
For improved performance, BltPrepare can examine the characteristics of the BLT and the associated surfaces to determine whether an accelerated form of the BLT can be used. After initializing the default handler, the display driver may include support for hardware or software accelerations. The driver may encapsulate this support within a #IFDEF block. The ENABLE_ACCELERATION directive is generally used to specify inclusion of the code for hardware accelerations. The ENABLE_EMULATION directive is generally used to specify inclusion of the code for software-accelerated emulation.
After setting the default handler, the S3Trio64 driver dispatches BLTs to hardware acceleration, if available, and then to software-accelerated emulation, if available.
The driver defines a macro that simplifies constructing calls to functions in the emulation library. The driver next checks whether the destination surface is in video memory. This is a very important check that most display drivers must make before using hardware acceleration. The issue is that on Windows CE, the display driver is used by GDI to render printer output as well as display output. The printer output is rendered in system memory, not in video memory. Most display hardware can only perform accelerated drawing when the destination surface is in video memory (for BLTs that don't take a source) or when both source and destination surfaces are in video memory (for BLTs that do take a source). If the hardware has this limitation, the driver must check the destination (or source and destination) before calling the acceleration.
As shown below, the driver evaluates the ROP code and directs the BLT to a supported hardware acceleration, when available. The ROP for SRCCOPY illustrates how the driver checks for a source surface in video memory before calling the SRCCOPY hardware acceleration.
The S3Trio64 display driver also demonstrates how to use the emulated BLT library. After setting the default BLT handler and handling hardware accelerations, the driver checks for possible software accelerations. When available, it sets the BLT function pointer to the corresponding function in the emulation library. The S3Trio64 driver encapsulates within a #IFDEF FB16BPP block all BLT handling where the destination is a 16-BPP surface. The driver attempts to accelerate a mask PATCOPY text BLT. Before doing so, it checks to see that the BLT is using a solid brush. In the case of a mask PATCOPY text BLT with a 1-BPP mask, the driver dispatches the BLT to the emulation library's 16-BPP Text function. When the mask is a 4-BPP mask, it dispatches the BLT to the emulation library's 16-BPP alpha Text function.
Before invoking a BLT function in the emulation library, the driver must always check for conditions that might prevent the BLT from using emulation. This is critical because the functions in the emulation library assume that the driver has validated the BLT before calling an emulation function. In the sample code, the driver checks for a solid brush. That's because pattern brushes aren't supported in the emulation library. There are other cases that the emulation library cannot handle, including color conversions, bit depth conversions, stretching, and transparency. As shown in the following, the driver checks these restrictions:
After validating that emulation can handle the BLT, the display driver examines the ROPs, dispatching supported ROPs to the appropriate emulation function. For simplicity, the driver specifies the ROP4 value. For masking BLTs, the entire WORD is used; whereas, for nonmasking BLTs, the least significant byte is used (the ROP3 value). ROPs are defined in Windows as a DWORD. In Windows CE display drivers, only the most significant WORD of the ROP is used. The lower WORD (ROP compiler directives) is ignored.
The following sample function demonstrates how to do 8-BPP to 16-BPP blits conversions with a SRCCOPY ROP, with transparency and with no stretching. It should be evident how to modify this code to not do transparency, or to use a different ROP or different bit depths. You can hook this blit with the following check in BltPrepare:
More Samples of Drivers That Use AccelerationsOther display drivers that are provided in the Embedded Toolkit demonstrate how to invoke hardware accelerations and make use of the emulation library. For hardware accelerations, see the S3Virge driver in the Platform\Cepc\Drivers\Display\S3virge folder. For hardware accelerations and use of the emulation library, see the Citizen driver in the Platform\Odo\Drivers\Display\Citizen folder.
How to Include Emulation and GPE Libraries in an Operating System ImageThe emulated BLT functions are compiled, then linked into a single library, Emul.lib. The display driver links to the emulation library through a link directive in the driver's SOURCES file. For example, the SOURCES file for the S3Trio64 display driver includes the Emul.lib file in its list of TARGETLIBS. This will cause it to link with Emul.lib. The GPE Library is provided in binary form in the Embedded Toolkit, and is similarly included in the driver's SOURCES file.
The S3Trio64 display driver is the default display driver for CEPC. The Platform.bib file in the Platform\Cepc\Files folder directs the ROMIMAGE tool to include the driver in the operating system image. Other CEPC display drivers may replace S364Trio. See the Platform.bib file for the list of environment variables that may be set to direct the ROMIMAGE tool to use a different display driver.
The ODO 2BPP driver is the default display driver for ODO. The Platform.bib file in the Platform\Odo\Files folder lists the environment variables that may be set to direct ROMIMAGE to use a different display driver.
Function Listing of Emulation Library
File Name Function ROP Src Bit Target Description Depth Bit Depth ====================================================================================== Ebalph02.cpp EmulatedBltAlphaText02 AAF0 02 Special-case fast Blt function for rendering anti-aliased text. Assumes mask surface contains the 4BPP alpha bitmap for the glyph. Ebalph16.cpp EmulatedBltAlphaText16 AAF0 16 Special-case fast Blt function for rendering anti-aliased text. Assumes mask surface contains the 4BPP alpha bitmap for the glyph. Ebcopy02.cpp EmulatedBltSrcCopy0202 CCCC 02 02 Implements BitBlt(SRCCOPY) Ebcopy08.cpp EmulatedBltSrcCopy0808 CCCC 08 08 Implements BitBlt(SRCCOPY) Ebcopy16.cpp EmulatedBltSrcCopy1616 CCCC 16 16 Implements BitBlt(SRCCOPY) Ebdinv02.cpp EmulatedBltDstInvert02 5555 02 Implements PatBlt(DSTINVERT) Ebdinv08.cpp EmulatedBltDstInvert08 5555 08 Implements PatBlt(DSTINVERT) Ebfill02.cpp EmulatedBltFill02 0000, FFFF, F0F0 02 Implements PatBlt(PATCOPY) for ROP F0F0, PatBlt(BLACKNESS) for ROP 0000, PatBlt(WHITENESS) for ROP FFFF Ebfill08.cpp EmulatedBltFill08 0000, FFFF, F0F0 08 Implements PatBlt(PATCOPY) for ROP F0F0, PatBlt(BLACKNESS) for ROP 0000, PatBlt(WHITENESS) for ROP FFFF Ebfill16.cpp EmulatedBltFill16 0000, FFFF, F0F0 16 Implements PatBlt(PATCOPY) for ROP F0F0, PatBlt(BLACKNESS) for ROP 0000, PatBlt(WHITENESS) for ROP FFFF Ebpinv02.cpp EmulatedBltPatInvert02 5A5A 02 Implements PatBlt(PATINVERT) Ebpinv08.cpp EmulatedBltPatInvert08 5A5A 08 Implements PatBlt(PATINVERT) Ebsand02.cpp EmulatedBltSrcAnd0202 8888 02 02 Implements BitBlt(SRCAND) Ebsand08.cpp EmulatedBltSrcAnd0808 8888 08 08 Implements BitBlt(SRCAND) Ebsand16.cpp EmulatedBltSrcAnd1616 8888 16 16 Implements BitBlt(SRCAND) Ebsinv02.cpp EmulatedBltSrcInvert0202 6666 02 02 Implements BitBlt(SRCINVERT) Ebsinv08.cpp EmulatedBltSrcInvert0808 6666 08 08 Implements BitBlt(SRCINVERT) Ebsinv16.cpp EmulatedBltSrcInvert1616 6666 16 16 Implements BitBlt(SRCINVERT) Ebspnt02.cpp EmulatedBltSrcPaint0202 EEEE 02 02 Implements BitBlt(SRCPAINT) Ebspnt08.cpp EmulatedBltSrcPaint0808 EEEE 08 08 Implements BitBlt(SRCPAINT) Ebspnt16.cpp EmulatedBltSrcPaint1616 EEEE 16 16 Implements BitBlt(SRCPAINT) Ebtext02.cpp EmulatedBltText02 AAF0 02 Special-case fast Blt function for rendering text, i.e., the ROP 0xAAF0 (solid-color fill with a mask) Ebtext08.cpp EmulatedBltText08 AAF0 08 Special-case fast Blt function for rendering text, i.e., the ROP 0xAAF0 (solid-color fill with a mask) Ebtext16.cpp EmulatedBltText16 AAF0 16 Special-case fast Blt function for rendering text, i.e., the ROP 0xAAF0 (solid-color fill with a mask)
Supporting Line Drawing in Windows CE Display DriversThe previous sections describe the various levels of BLT processing that are available beginning in Windows CE 2.0. For the most part, all of the discussion is relevant for line drawing as well. The exception is that the emulation library that is provided in the Embedded Toolkit does not provide software-accelerated line drawing. The embedded developer can add functions to the library.
Handling Line Drawing and Accelerations in a Display DriverIn a Windows CE display driver, the driver routes line drawing to either GPE (the default) or directly to the hardware. The S3Trio64 display driver demonstrates how these methods are invoked:
Line drawing begins with a call to the driver's Line function. Typically, GPE is initialized to handle default line drawing. For improved performance, Line can examine the characteristics of the line drawing and the associated surfaces to determine whether an accelerated form of line drawing can be used. The S3Trio64 driver encapsulates hardware accelerations within a #IFDEF ENABLE_ACCELERATION block. The driver checks for a destination surface in video memory. The driver checks the line drawing parameters. The 0x0D0D mix (R2_COPYPEN) is selected for hardware acceleration. The function pointer is set to the driver's AcceleratedSolidLine function.
Article ID: 247058 - Last Review: April 14, 2004 - Revision: 2.1