Comparison of Methods for displaying BMP images in resources using WinCE

This article is post, original post address

Http://www.cnblogs.com/we-hjb/archive/2010/02/09/1666778.html

 

 

The previous section describes how to directly operate the framebuffer of wince. Here we will introduce a method to display BMP images in resources by writing framebuffer. Compare it with using GDI to see if direct read/write framebuffer can improve efficiency?

The key code is as follows:

Hscrdc = createdc (text ("display"), null );
Hmemdc = createcompatibledc (hscrdc );
BMP. loadbitmap (makeintresource (idb_bitmap1 ));
BMP. getbitmap (& BMP info );
SelectObject (hmemdc, BMP );

Bitblt (hscrdc, 0, 0, dwwidth, dwheight, hmemdc, 0, srccopy );

The key code is as follows:

Hinstance hinst = (hinstance): getmodulehandle (null );
Hrsrc HRC = findresource (hmodule) hinst, makeintresource (idb_bitmap1), rt_bitmap );
Hglobal = loadresource (null, HRC );
Dwbufsize =: sizeofresource (null, HRC );
Gbmpbuf = (pbyte): lockresource (hglobal );

Memcpy (gplcdbuf, gbmpbuf, dwbufsize );

The BMP images loaded in the resource are saved directly from the wince video memory, as shown in.

Shows the effect displayed by using bitblt.

Shows the effect of writing video memory directly.

We can see that bitblt is used, and the BMP in the resource seems to be actually displayed. The color is restored by using the direct screen writing method, but it is shifted to the right. As shown in the time they were used, GDI used 145 ms and directly wrote the memory about 1 ms.

Obviously, direct write memory is much faster than bitblt, but the location is biased. Is there a faster way to use GDI? Why is it so slow. Try to use another method of GDI for display. The Code is as follows:

BMI. bmih. bisize = sizeof (BMI. bmih );
BMI. bmih. biwidth = dwwidth;
BMI. bmih. biheight =-dwheight;
BMI. bmih. biplanes = 1;
BMI. bmih. bibitcount = (byte) BMP info. bmbitspixel;
BMI. bmih. bisizeimage = 0;
BMI. bmih. bixpelspermeter = 0;
BMI. bmih. biypelspermeter = 0;
BMI. bmih. biclrused = 0;
BMI. bmih. biclrimportant = 0;
BMI. bmih. bicompression = bi_bitfields;
* (DWORD *) (& BMI. rgq [0]) = 0xf800;
* (DWORD *) (& BMI. rgq [1]) = 0x07e0;
* (DWORD *) (& BMI. rgq [2]) = 0x001f;

Stretchdibits (hscrdc, 0, 0, dwwidth, dwheight, 0, 0, dwwidth, dwheight,
Gbmpbuf, (pbitmapinfo) & BMI, dib_rgb_colors, srccopy );

Using this method, the display effect is exactly the same as that of ddraw, and the speed is equal to or equal to that of bitblt. Why? Xuan Miao is in BMI. rgq. The bit mask set here is the same as that in the display driver. Therefore, the effect is equivalent to writing the screen directly, and the color is correct, and the efficiency is high. Bitblt's default bit mask estimation is inconsistent with that in the driver, resulting in more memory operations, which takes some time. To verify this idea, modify the BMI. rgq settings as follows:

In the actual development process, pay attention to this small detail, which may improve some efficiency.

* (DWORD *) (& BMI. rgq [0]) = 0xf800;
* (DWORD *) (& BMI. rgq [1]) = 0x03e0;
* (DWORD *) (& BMI. rgq [2]) = 0x001f;

In this case, the color display is the same as bitblt, and the time is similar. It seems that it will be slow without using GDI, and bit mask is the key. Bit masks of 16-bit colors mainly include the following types.

// Xrrrrrgg. gggbbbbb 0x7c00 0x03e0 0x1f
// Rrrrrxgg. gggbbbbb 0xf800 0x03e0 0x1f
// Rrrrrggg. ggxbbbbb 0xf800 0x07c0 0x1f
// Rrrrrggg. gggbbbbb 0xf800 0x07e0 0x1f