Verify GDI on a Video Memory Surface (Compact 7)
3/12/2014
The Graphics Device Interface (GDI) Test exercises the graphics device interface. This test verifies that basic shapes, including rectangles, triangles, circles, and ellipses, are drawn correctly. It also examines the color palette of the display, verifies that the display is correctly divided into multiple regions, and tests whether a device context can be properly created, stored, retrieved, and destroyed.
The test compares the display output to the output of a GPE-based display driver. If the output of the display driver does not match the output rendered by the GPE-based display driver, the test lists the coordinates and pixel values that do not match.
To view the output of a GPE-based display driver, boot a target device with the flat display driver and then run the test.
Test Prerequisites
Your device must meet the following requirements before you run this test.
The GDI Test requires that the Windows Embedded Compact-based device be equipped with display hardware that corresponds to the driver being tested.
If you run the test and enable manual verification, the device must be equipped with a display that you can view. In addition, the device must have a keyboard, mouse, touch screen, or other hardware for data input. By default, manual verification is disabled.
The following table shows the software requirements for the GDI Test.
| Requirements | Description |
|---|---|
Tux.exe |
Test harness, required for executing the test |
Kato.dll |
Logging engine, required for logging the test data |
Gdit.dll |
Main test library |
Ddi_test.dll |
Graphics Primitive Engine (GPE)-based display driver that the GDI API uses to verify the success of each test case. If Ddi_test.dll is unavailable, run the test with manual verification. |
This test requires that you include a graphic display driver in the operating system design that is appropriate for the display hardware on your device.
Note: When you run the GDI Test, the Windows Embedded Compact Test Kit (CTK) temporarily copies files to the root directory of the device. While the test runs, the test dynamically consumes program memory on the device. Before running the test, verify that there is at least 3.7 megabytes (MB) of free storage memory on the device. Also verify that there is at least 2.0 MB of free program memory on the device. If there is not sufficient space in the root directory of the device or there is not sufficient program memory, the test cannot run.
Subtests
The table below lists the subtests included in this test.
| SubTest ID | Description |
|---|---|
100-104 |
Clip: Tests the functionality of clipping using different shapes and verifies the functionality of complex clip regions. |
200-231 |
Draw: Calls functions that draw and functions that apply complex effects to drawing. These test cases perform blitting, line drawing, filling, color table manipulation, bitmap type creation, and device attribute modification. |
300-307 |
Pallette: Verifies color matching and color conversion for palettes, and modifies associated palettes. |
500-512 |
Region: Tests region management by calling functions that modify region rectangles. |
600-608 |
Brush and pen: Assesses the functionality of brushes and brush alignments. |
700-710 |
Device attribute: Verifies device attributes and exercises functions that modify device attributes. |
800-808 |
Device context: Creates, retrieves, saves, and restores a device context. |
900-905 |
Device object: Calls functions that retrieve, modify, and delete GDI objects. |
1000-1011 |
Font: Verifies font enumeration, selection, and attributes. |
1100-1108 |
Text: Writes text to various locations on the display. If the font required by the test is not available, some test cases do not run. Note: Test case 1100 checks for the presence of a hardware keyboard and fails if it is not present. If the device being tested does not have a keyboard, ignore the results of test case 1100. |
1200-1205 |
Print: Passes bad parameters to printing functions. |
1300-1303 |
Verify: Assesses the functionality of test verification functions such as CheckScreenHalves and CheckAllWhite. |
1400, 1401 |
Manual: Manually tests font drawing. You can use these test cases to exercise code paths. To step through these test cases, press the left SHIFT key. |
Setting Up the Test
This test has no additional requirements, beyond the standard test environment setup.
Running the Test
"Command Line Parameters for the Graphics Device Interface Test:"
The following table shows the command line parameters for the Graphics Device Interface Test.
| Command line parameter | Description |
|---|---|
-c "/?" |
Displays information about command-line options for the GDI Test. |
-c "/OutputBitmaps" |
Instructs the GDI Test to save a bitmap image for each failure. The .bmp file can assist you in debugging the problem that caused the unexpected output. |
-c "/BitmapDestination path" |
Specifies where to save the bitmap image for a failure. |
-c "/NoVerify" |
Instructs the GDI Test to not use driver verification. By default, the GDI Test uses driver verification. |
-c "/ForceVerify" |
Forces the GDI Test to perform verification. If you specify this option, the GDI Test performs verification even if there is little memory available. If the Ddi_test.dll module is not available, test cases fail. |
-c "/ManualVerify" |
Instructs the GDI Test to support manual verification. During manual verification, to step through test cases, press the left SHIFT key. |
-c "/Monitor n" |
Specifies the screen to run the GDI Test on. The parameter n is an integer from 1 to 4.This option applies only to the Win_Primary surface and only to a Windows Embedded Compact based device with multiple screens. If you specify this option and the option does not apply, the GDI Test ignores the option. |
-c "/MonitorSpread" |
Runs the GDI Test spread across multiple screens. This option applies only to the Win_Primary surface and only to a Windows Embedded Compact based device with multiple screens. If you specify this option and the option does not apply, the GDI Test ignores the option. |
-c "/Width size /Height size" |
Specifies the width and height of the surface that the GDI Test uses. *Minimum width is 176. *Minimum height is 176. *Width and height must each be a multiple of 2. |
-c "/Surface All" |
Instructs the GDI Test to cycle through all known surfaces. This cycling can require significant time. The cycling requires significant storage space on the device because the Windows Embedded Compact Test Kit (CTK) stores test results in a file on the device. |
-c "/Surface surfacename" |
Specifies a type of surface to test. For surfacename, use one of the following values: *Win_Primary. *GDI_VidMemory. *GDI_SysMemory. *1BPP_BITMAP. *1BPP_DIB_RGB. *2BPP_DIB_RGB. *4BPP_DIB_RGB. *8BPP_DIB_RGB. *16BPP_DIB_RGB555. *16BPP_DIB_RGB565. *24BPP_DIB_RGB. *32BPP_DIB_RGB8888. |
-c "/SetDisplay driver.dll" |
Runs the GDI Test on a secondary display driver. |
-c "/AlwaysVerify" |
Forces a driver verification against the test display driver for every operation. This option is time-consuming and may significantly increase the overall test duration. |
-c "/NoRotate" |
Disables dynamic screen rotation during the GDI Test, if such is supported by the display driver. |
-c "/NoResize" |
Disables dynamic resolution resize, if such is supported by the display driver. |
Verifying the Test
When the test completes running, verify that "PASS" appears in the test log for all sub-tests.
Troubleshooting the Test
Test case 1100 checks for the presence of a hardware keyboard and fails if one is not present. If the device being tested does not have a keyboard, ignore the results of test case 1100.
For additional platform specific issues, consult the CTK articles on the TechNet wiki.