C ++ transparent Bitmap (2)

Transparent bitmap

Ron gery
Microsoft Network Development Technical Team

 

Summary
This articleArticleSeveral methods for using bitmap in Microsoft Windows graphics environment to achieve transparency and shielding effect are discussed, including simulating and using special drive functions. Contains a small sample applicationProgramTransblt details most of the methods discussed in this article.

Introduction
With the transparent background mode (set using the setbrmode function), an application can use transparent text, transparent lines, and transparent shape brushes. Sadly, Microsoft Windows does not provide a simple interface for transparent bitmap. (Yes, it provides but does not provide extensive support, as mentioned in "Easy bitmap transparency" below ). Fortunately, by using a shielded bitmap and several calls with carefully selected grating operations, an application can mimic this effect.

What is transparent bitmap? It is a bitmap and can still be seen through a part of its target file. A simple example is a Windows-based image similar to a control panel image. The control panel image itself is basically a rectangle. When it is minimized, the desktop can be seen through the bitmap of this rectangular image. From an idealized point of view, this image bitmap is designed to grow a square. Some pixels are designated as transparent so that when the bitmap is used, those pixels will not block the target file. Transparent bitmaps can become more interesting by moving non-rectangular images. The imitation method described below can be used to complete these transparent effects.

Symbol
This article uses the word transparency and opacity to depict pixels in the source bitmap. Transparent pixels are those that do not affect the target file. Non-transparent pixels are the pixels that draw on the target file and replace the original objects in this position.

White and black are assumed to be values of all 1 and all 0 respectively. This is true on all known windows display drives, including the palette device.

Basic operations involve block transfer from the source file to the target file. Additional block transfer related to monochrome shielding is also required. Source and target files-represented by their device context-hdcsrc and hdcdest can be bitmap or device surface. The shielding mentioned by hdcmask is assumed to be a dc-compatible monochrome bitmap.

Background
Before discussing actual transparent imitation, we should define and review some basic graphic concepts.

Grating operation
The last parameter of the bitblt function specifies a grating operation (ROP), which clearly defines how the source file, target file, and mode (defined by the selected brush) to form a target file. Because a bitmap is only a set of bitvalues, the grating operation (ROP) is only a Boolean Equation operated on the position. The device used accordingly. The bitmap represents different things.

• On a multi-color device, each pixel is represented by a single set. They either form an index pointing to a color or represent a color directly.
  
• On a monochrome device, each pixel is represented by a single bit. 0 indicates black and 1 indicates white.

For all device types, the grating operation (ROP) is simply performed on the display position without considering their actual meaning.

One trick is to merge bits in a meaningful way. For the programmer's reference in the Windows 256 software development kit, page 3: Appendix A in messages, structures, and macros lists possible triple grating operations (ROP ). Raster operations (ROP) provides a variety of ways to merge bitmap data, and you can often use more than one method to get the desired effect. This article only discusses four of them.

Pre-defined name	Boolean operation	Usage in transparent Simulation
Srccopy	SRC	Directly copy the source to the target
Srcand	SRC and dest	Black part of the target file corresponding to the black area of the source file.
SRCINVERT	Src xor dest	Insert the source to the target. During secondary use, the target is restored to its original state. The srcpaint operation can be replaced under certain conditions.
Srcpaint	SRC or dest	Fl the non-white areas in the source file to the target file. The black area in the source is not converted to the target.

Some printers do not support some grating operations, especially those involving the target file. Because of this, the techniques described in this article specifically aim at display and may not work on certain printer devices, such as postscript printers.

Transparent shielding
In this article, the word "Mask" is not something Batman wears on his face. It refers to a bitmap that limits the visible part of other bitmaps. The "Mask" has two controls: the opaque part (black). The source bitmap in this part is visible and the transparent part (black), and remains unchanged in this part of the target file. Because a mask is composed of only two colors, it can be conveniently represented by a monochrome bitmap, although it can be a black-white bitmap. As discussed in the following "Real blocking methods" and "methods for blackening source files", block passing blocking is used as part of most data block passing processes, it sets the destination file for the final transparent data block transfer of the source bitmap. The transblt sample application uses transparent pigments with 1 and monochrome shielding of non-transparent pigments with 0. The application can convert these two values if needed, and supplement some of the monochrome to color conversion to be described in this section.

In addition to providing convenience for transparency, blocking is also useful in imitating complicated tailoring operations. This cropping operation cannot be effectively processed in the use area. The mesh effect transmitted by a blocked data block will cut off part of the source bitmap. For example, to show only one circular area in the bitmap, you can create a circular area with the same size as the source file and draw a transparent circle in the corresponding area. The mechanism for executing this blocked data block transfer will be described in the "real blocking method" and "Method for blackening the source file.

Conversion from monochrome to color
Transparent simulation also involves the conversion from a Windows-based monochrome bitmap to a color bitmap. And vice versa. Windows-based text foreground and background colors are used to convert between two formats. When bit transfer is performed on a color target file, a monochrome source Bitmap (and/or a paint brush when applicable) is performed in the actual grating operation (ROP) previously implemented in this bit is converted to the background color. On the contrary, when the target file is a monochrome, Windows converts the color source to a monochrome. In this case, all pixels in the color bitmap that are consistent with the background color change to 1, and all other pixels are converted to 0. Because the following examples all use monochrome shielding, it is very important for an application to correctly set the background color and foreground color before performing the block operation.

Performance and screen blinking
The reason for the slow bitmap operation is because of the number of affected bits. In addition, this is even more serious when the screen is flashed due to direct operations. When the size of the affected area increases, things only get worse. Although there is no magic way to increase the speed, you can use the shadow bitmap to delete the visible flashes. First, the application copies the area of the screen to be affected to the storage bitmap, and then the application performs bitwise operations on the shadow bitmap instead of the screen (for example, transparent effect ). Finally, the shadow is copied to the screen. The result is only one block transfer, which affects the screen, so the flash is gone. Obviously, two additional block operations cause a slowdown (although block transfer on some devices can be a bit more than block transfer that has accessed the screen ), however, depending on the size of the bitmap and the surprising operation, the operation may disappear and make people feel faster. Things become clearer because they are not confusing. Whether the shadow operation is appropriate depends on the specific needs of the application.

Block blocking does not need to be modified on a part of the source bitmap that will be useful soon. Blocking block transfer involves step operations and blocking sets all transparent elements to 1, so the opacity element is set to 0. Below are the basicCode:

// Set up destination for monochrome BLT (only needed for monochrome
// Mask). These are the default values and may not need to be
// Changed. They shoshould also be restored.
Setbkcolor (hdcdest, RGB (255,255,255); // 1 s --> 0 xffffff
Settextcolor (hdcdest, RGB (0, 0, 0); // 0 s --> 0x000000

// Do the real work.
Bitblt (hdcdest, X, Y, dx, Dy, hdcsrc, x0, y0, SRCINVERT );
Bitblt (hdcdest, X, Y, dx, Dy, hdcmask, 0, 0, srcand );
Bitblt (hdcdest, X, Y, dx, Dy, hdcsrc, x0, y0, SRCINVERT );

The following three steps are taken to process blocked block transfer:

1. Step 1 (pass the bitmap with SRCINVERT) returns the source bitmap to the target file. This seems a bit interesting, but the second step may have the effect of restoring the target file to the original state.
2. Step 2 (bit block transfer with srcand) is a blocking operation. When shielded from the target file phase, all the transparent pixels do not change the pixels of the target file, while the non-transparent pixels directly change the target file to black. Now the target file contains an image outlined in the opaque part of the source file, and its own difference or image in the transparent part.
3. Step 3 (bit block transfer with SRCINVERT) is different from the source file or is sent to the target file. Transparent pixels are restored to the source State (which can be achieved in two steps), and opaque pixels are copied from the source files in the season.

Unfortunately, when the three steps are executed, the target file looks ugly for a while, and directly performing three passes on the screen causes the screen to flash.

Method for blacklisting source files
As long as you plan a bit when creating the source bitmap, transparent block transfer can be reduced to only two calls. The screen remains the same as the above example, but the source file must pass the code in the blocked block as follows:

// Set up destination for monochrome BLT. These are the default
// Values and may not need to be changed. They shoshould also be
// Restored.
Setbkcolor (hdcdest, RGB (255,255,255); // 1 s --> 0 xffffff
Settextcolor (hdcdest, RGB (0, 0, 0); // 0 s --> 0x000000

// Do the real work.
Bitblt (hdcdest, X, Y, dx, Dy, hdcmask, 0, 0, srcand );
Bitblt (hdcdest, X, Y, dx, Dy, hdcsrc, x0, y0, srcpaint );

The second shielding operation is used to make the non-transparent pixels black and keep the rest unchanged. The source file is connected to the source file, and then painted on the black part of the target file. Because the source file only has black pixels where it is to be transparent, or the operation keeps the target file unchanged in those transparent areas. Note that SRCINVERT pop can replace srcpaint In the second block transfer call era and achieve various effects. The possibility that the source shield settings are deleted is the only case where XOR is different from or.

In this way, screen flickering becomes less eye-catching, and transparency looks good once the source file is set to black again. Windows also uses this mechanism to display images on the screen. The icon is divided into two parts stored in the. ICO file, the two parts "XOR mask" and the bitmap itself. Because the bitmap is as small as the icon, the transparency is very smooth.

Bitmap transparency
Bitmap transparency usually refers to processing. This processing extracts a bitmap and changes the color of the bitmap to transparent. When the bitmap is transmitted to the screen by blocks, the target file can be seen through the transparent color of the bitmap. An application can simulate this operation by constructing an appropriate shielding technique that is described in the preceding "True blocking method" and "method that blackens the source file. The following section describes how to construct a shield for display devices that cannot perform transparent block transfer by imitating the bitmap transparency.

It is quite easy to construct a monochrome shielding from a color bitmap, because the built-in color passed by bit blocks-the monochrome conversion automatically completes all this work. The target is a block where all opacity elements are set to 0 and all transparency elements are set to 1. Set the background color to transparent. There is no need to set the text foreground color because it cannot be used for color-monochrome conversion (so non-Background pigments are set to 0). The following code completes this task:

Setbkcolor (hdcsrc, rgbtransparent );
Bitblt (hdcmask, 0, 0, dx, Dy, hdcsrc, x0, y0, srccopy );

The Code constructs a source file that is equivalent to a mask where 1 is transparent and 0 is elsewhere. This copies the previously used blocking.

Shielding
It is time to use the blocking method described above. The real blocking method does not require additional work: creating blocking and the source file does not need to be processed. The transfer of three single-digit blocks does cause the screen to flash, but now there is only one of the three.

On the other hand, the method of blackening the source file requires some additional work on the source bitmap to obtain the correct input scheme-The Transparent Bit needs to be blackened. Of course, if the transparent color is black at the beginning, the figure is ready to run. The installation of transparent coloring on the source file is very similar to the installation of non-transparent coloring on the target file. This is done when shielding is used, as shown below:

Setbkcolor (hdcsrc, RGB (000000, 0); // 1 s --> black (0 x)
Settextcolor (hdcsrc, RGB (255,255,255); // 0 s --> White (0 xffffff)
Bitblt (hdcsrc, x0, y0, dx, Dy, hdcmask, 0, 0, srcand );

Currently, two bit Block passing methods are used for Transparent Bit block passing.

Once the actual Transparent Bit block is passed, the source bitmap should be restored to its initial color:

Setbkcolor (hdcsrc, rgbtransparent); // 1 s --> transparent color
Settextcolor (hdcsrc, RGB (000000, 0); // 0 s --> black (0 x)
Bitblt (hdcsrc, x0, y0, dx, Dy, hdcmask, 0, 0, srcpaint );

Because the source bitmap must be changed and then restored, the total number of bit blocks transmitted is 4. This slows down the processing, but because two of the bit Block passing are in the storage bitmap instead of on the screen, the screen blinking is reduced compared with the real screen method. If the source bitmap can keep the Transparent Bit Set to black, two transfer blocks can be avoided together and only two are required for operation. This is actually necessary for animation production.

Simple bitmap transparency
Some device drives support block transfer. One drive indicates the ability of the CI-TRANSPARENT using capsi capability returned by the getdevicepaps function. In a special background mode, newtransparent indicates that later block transfer is transparent block transfer. The current background color of the target file is transparent. When this capability applies to the drive, the basic transparent block transfer can be executed as follows:

// Only attempt this if device supports functionality.
If (getdevicecaps (hdcdest, caps1) & c1_transparent)
{
// Special transparency background Mode
Oldmode = setbkmode (hdcdest, newtransparent );
Rgbbk = setbkcolor (hdcdest, rgbtransparent );
// Actual BLT is a simple source copy; transparency is automatic.
Bitblt (hdcdest, X, Y, dx, Dy, hdcsrc, x0, y0, srccopy );
Setbkcolor (hdcdest, rgbbk );
Setbkmode (hdcdest, oldmode );
}

This makes things easier. Unfortunately, few device drives currently support transparent block transfer-the block transfer feature is not available for those installed in windows3.1. This should change in the near future.

And currently, windows. H does not include the definition of any of these new variables. Instead, mmsystem. The H file provides definitions. This file can be found in the software development kit (SDK) of windows3.1.

Transparency with independent device Bitmap (DIB)
If the source bitmap is a device-independent Bitmap (DIB) format, you can use a device-independent Bitmap (DIB) as the source file. Shielding and simple operations on the color table can be greatly simplified. The processing process is the same as discussed above. The processing application can perform conversion of all colors-monochrome and monochrome-color by changing the color table, as shown below:

Save a copy of the color table;
// Build the mask.
For (every color in the color table)
{
If (color = rgbtransparent)
Color = white;
Else
Color = black;
}
// Prepare destination by blting the mask.
Stretchdibits (hdcdest, lpdib, srcand); // (yes, there are more
// Parameters .)

// Now prepare "blacked out" source for the mask BLT.
For (every color in the color table)
{
If (color = white) // (white from abve change)
Color = black;
Else
Color = original color from color table;
}
// Transparently BLT the source.
Stretchdibits (hdcdest, lpdib, srcpaint); // (yes, there are more
// Parameters .)

// To restore DIB to original state, restore original color table.

The key to this method is that you only need a backup of the bitmap because it relies on the color table conversion to act as the screen and as the source file. No matter whether the Device Independent Bitmap (DIB) format is converted into the Device Dependent format, the additional inconvenience persists.