Fast region creation on WinCE/PocketPC

• Download FreeFormPPC.zip - 65.4 KB
• Download FreeFormPPC_src.zip - 41.9 KB

Introduction

Modern applications often have a customized, "skinned" look. There are a lot of tools, libraries and tutorials on creating skinned apps for desktop Windows systems. Unfortunately this is not the case with WinCE or PocketPC. If you try to adapt ideas or code from Win32 programs, you will experience a lot of challenges, just as I had while creating the Skinnable Dialogs Framework. A very basic feature of a skinnable application is to have custom-shaped controls or main windows. Creating non-rectangular windows is a relatively easy task in the Win32 world. All you have to do is, create a region based on a bitmap mask and set it for your window with the SetWindowRgn API.

Creating a region is the first step towards a custom-shaped window.
Every region creator that I've seen so far uses the same idea:

• uses a bitmap mask to define the visible and transparent regions of a window
• calls the GetPixel funcion on the bitmap mask to see which areas of the window should be transparent
• then calls CreateRectRgn to create new rectangular regions based on pixels or pixel blocks
• and finally combines these smaller regions into the final, custom-shaped region with the CombineRgn function.

But have you tried this approach on PocketPC or WinCE? Well I have, and the results were very disappointing. The smiley bitmap above was parsed for several minutes!
I found that region functions work well on WinCE only if you want to combine a couple of rectangular regions. But when it comes to hundreds of small regions (just as with a bitmap mask), CombineRgn becomes unacceptably slow.
In this article I'd like to present a much faster solution for custom region creation using the ExtCreateRegion API. The code works fine on WinCE/PocketPC and also on Win32. I've tested it with Embedded Visual C++ 4 and Visual Studio 2005, too.

The solution

The CRegionBuilder class (see files RegionBuilder.h and RegionBuilder.cpp) has only one public function, BuildRegion. It uses the ExtCreateRegion API to create a region from manually built region data. The region data consists of a header (a RGNDATAHEADER structure) and an array of RECT structures that make up the region.
The BuildRegion function takes two parameters, a bitmap handle of a loaded bitmap and a pointer to store the resulting region handle:

    RegionBuilderError BuildRegion(HBITMAP hBmp, HRGN *pDest);

The function includes every non-black pixel in the resulting region.
Possible return values are: rbeOK, rbeNoMem and rbeGDIError as defined in RegionBuilder.h. If memory allocation fails, it returns rbeNoMem. If any of the used GDI functions return an error, it returns rbeGDIError. If all goes fine, the function return rbeOK and the resulting region handle will be copied to the destination.

Some tips:

• Do not call DeleteObject on the region handle until your window is visible, instead, free it in OnDestroy.
• Drawing custom-shaped windows on CE devices is considerably slower than drawing regular windows, so don't expect hyper-performance.
• If you use a very complicated bitmap mask that would result in a thousands of region RECTs (eg. 640x480 "random noise"), you might experience sudden device crashes or other drawing problems.

How it works

The BuildRegion function first gets bitmap dimensions with the GDI GetObject function. To avoid the slow GetPixel function, it reads bitmap bits directly. But the GetObject function does not return a pointer to the bitmap bits unless the bitmap was created with CreateDIBSection. So, BuildRegion creates a new, monochrome bitmap using this function and then copies the source bitmap to it with BitBlt. Using a monochrome version of the bitmap saves a lot of precious memory.

After the monochrome copy has been created, the function loops through the bitmap bits to see how much memory will be required for the RECT array. If there are horizontal lines in the bitmap, they will be packed into one RECT.

Then the function allocates a proper memory block for the rectangles and loops through the bits again to build the RECT array.

It loops twice through the bitmap, so it allocates only the required amount of memory. Despite this it's still pretty fast I think. A lot faster than the ordinary GetPixel + CombineRgn method.

Have fun!

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 4 of 4 (Total in Forum: 4) (Refresh) FirstPrevNext

Would be great to have its wrapper in .NET CF! Alexander Aphonin 4:33 4 Feb '09   Thanks Sign In·View Thread·PermaLink Transparent window on Windows Mobile Voland.cpp 0:52 10 Oct '08   Hello Dzolee, Thank you very much for this wonderful article! It's just what I was searching for almost a week. I need to make rounded edges for a window. I have tried a lot of things: HOLLOW_BRUSH and own realization of WM_ERASEBKGND, AlphaBlend... But only your solution is the most adequate for the purpose I need. Meanwhile I have a question that is a little offtopic, but somewhat related at the same time: Is it possible to make a transparent window on Windows Mobile? As layered windows (SetLayeredWindowAttributes) aren't supported on WM, as I know (correct me if I'm wrong), what can be the best solution for this? Regions can't be used as the excluded "transparent" region no more belongs to our window and is controlled by the system, so we can't draw on it. I was thinking about using HOLLOW_BRUSH and to handle the WM_ERASEBKGND message something like this: - Hide the window - BetBlt the required part of the desktop DC to the DC of our window - Draw something on the DC - Show the window I haven't yet tested this solution. It should be very resource intensive. What do you think about this idea? Maybe more effective one exists? With regards, Voland Sign In·View Thread·PermaLink Re: Transparent window on Windows Mobile dzolee 0:57 10 Oct '08   Hi, I'm not up-to-date with the latest WM versions - but with PPC2003 and WM5.0 OS-es, you had to code transparency manually. If you want 50% transparency, then you have to mix pixels manually. That is how it was, at least. Very resource intensive, and quite challenging. Sign In·View Thread·PermaLink 3.00/5 (2 votes) Thanks! Quentin Pouplard 9:57 5 Aug '07   Well it just works! Thanks for this piece of code. -- Quentin Pouplard http://www.pocketcm.com Sign In·View Thread·PermaLink

Last Visit: 19:04 9 Feb '10     Last Update: 19:04 9 Feb '10 1