Efficient textures for Windows Mobile

Efficient textures for Windows Mobile

Original article: http://www.cppblog.com/guogangj/archive/2010/06/20/118316.html

The concept of bitmap is a crucial concept for computer graphics. Anything we see on the screen is actually bitmap for computers. Simply put, whether you want to display text, lines, or BMP, PNG, JPG, GIF, or other image files, you must directly or indirectly convert them into the bitmap recognized by the computer display device, to display on the screen.

I recently took over a project on the Windows Mobile platform, mainly for UI beautification. textures are a large part of it. The biggest problem I encountered was the efficiency of textures, how to efficiently draw images in a memory to achieve smooth and smooth UI animation. I tried a lot of methods, even DirectDraw, but I found that DirectDraw has no advantages in addition to making the code more complex without hardware support. Next, let's analyze how to exert the power of GDI as much as possible.

There are several texture-related functions:
Bitblt: the most basic block transfer function.
Stretchblt: similar to bitblt, it supports image stretching and compression. When there is no need to stretch or compress, its effect is similar to bitblt.
Transparentblt: Compared with stretchblt, it has a "color keying" function, which can trim the color of a certain color or a certain range without being transferred, to draw irregular images.
Alphablend: Compared with stretchblt, it supports Alpha mixing, that is, the "Translucent" effect, and the effect is better than the simple "golden color.

These functions are better than each other, but they also mean a lower efficiency. In general, they are similar. The larger the computing workload, the slower the process, however, the test shows that this is not an absolute one, which will be mentioned later.

After learning about these functions, we started to load an image to observe the effect. I prepared a 320*320 PNG Image and loaded it using the iimage interface provided by Windows Mobile 6.0, convert it to a bitmap to obtain hbitmap. You can use the search engine to search for "iimage usage" and other keywords to load the PNG code, which is skipped here.

After the image is loaded, create a DC (device context) compatible with the device display device, select the loaded bitmap, and draw it with bitblt. The Code is as follows (for the sake of simplicity, only key code is pasted, and resource release is not considered ):
HDC hwnddc = getdc (hwnd );
HDC hmemdc = createcompatibledc (hwnddc );
SelectObject (hmemdc, hbitmap); // hbitmap is the previously loaded image.
Bitblt (hwnddc, 0, 0, iwidth, iheight, hmemdc, 0, 0, srccopy );

We add some debug code to observe the execution time of bitblt, which is about 50-60 ms on my simulator. I found that this speed is not fast. In principle, bitblt should be able to be completed within a very short period of time (1-2 ms), and only in this way can the "smooth" UI animation effect be realized. Otherwise, it will not be slower if there are more images.

I tried to modify the last parameter of bitblt. I found that it was converted to notsrccopy, which was slower and changed to more than 70 ms. This means that the operation is more complicated. This is not a simple memory copy; when I change the last parameter to blackness or whiteness, the speed will be very fast. 1 ms-2 ms can be completed. Obviously, for bitblt, set all the targets to black or white, the computation is much less than pixel transfer. In the experiment, we replaced bitblt with several other functions. The effect is not much different from expectation. If the image needs to be stretched, It will be executed more slowly, but if the image is not stretched but compressed, that is to say, the display is reduced, and the execution speed is faster. Some accidents are caused by the fact that the compressed image becomes smaller and the number of pixels to be transmitted decreases.

After many attempts, I finally made some breakthroughs in how to improve the drawing efficiency. I finally found that if I first saved the bitmap in a dc-compatible bitmap, use this bitmap to transmit pixels to the target device, which is extremely fast. Code:
HDC hwnddc = getdc (hwnd );
HDC hmemdc = createcompatibledc (hwnddc );
HDC hmemdctoload = createcompatibledc (hwnddc );
Hbitmap hmembmp = createcompatiblebitmap (hwnddc, iwidth, iheight); // The compatible bitmap
Hgdiobj holdbmp = SelectObject (hmemdc, hmembmp );
SelectObject (hmemdctoload, hbitmap );
Bitblt (hmemdc, 0, 0, iwidth, iheight, hmemdctoload, 0, 0, srccopy); // do this in Initialization
Bitblt (hwnddc, 0, 0, iwidth, iheight, hmemdc, 0, 0, srccopy); // This bitblt's speed is very fast

The first call of bitblt can be regarded as initialization. We calculated the time consumption of the second bitblt, which is only 1-2 ms. It is very good. After analysis, I think the reason should be this (not all right, if any, please point out ):

Bitblt can perform real memory copy only when the bitmap format is completely consistent. Otherwise, the conversion requires CPU time and therefore is slow.

How can we know the bitmap format? GetObject can be seen as follows:

As shown in, BMP is the information of the bitmap loaded from the PNG file, while BMP 2 is the information of the bitmap created with createcompatiblebitmap. From this we can see that the former is a 24bit bitmap, that is, a pixel is represented by three bytes, while the latter is a 16-Bit Bitmap. A pixel is represented by two bytes. This bitblt needs to be converted during execution, so it takes time. In fact, bitmap differences may be more complicated than this. If we talk about device-independent bitmaps, We can't end up talking about them ......

All in all, in order to improve the efficiency, we need to find ways to convert the loaded bitmap into a device-compatible bitmap. When drawing, bitblt is directly compatible with these devices to achieve efficient bitmap rendering.

Bitblt is the main function discussed above. What about several other BLT functions? I have tried it. Apart from alphablend, the BLT speed from the compatible bitmap to the device has been significantly improved, while alphablend cannot work normally, because the compatible bitmap does not contain the alpha channel, alphablend seems to require a 32-bit argb bitmap to work normally. This problem has not been solved for a long time. If any reader has any idea about how to improve the efficiency of alphablend, please contact me and I am in urgent need of such technical materials.

Therefore, I come to the following conclusion: After loading a bitmap from a file (or resource), convert the bitmap to a device-compatible bitmap, this allows bitblt to directly use memory copy when executing srccopy, which is very fast. Even if you need to perform operations such as stretching, compression, and coloring, the bitmap compatibility speed is quite good, when alphablend is used, if it requires high efficiency, we should avoid drawing large bitmaps from the design. Instead, we should use small bitmaps. When we do not need to execute Alpha mixing for each frame, so as not to affect the smoothness of the screen.