Ron Gery
Microsoft Network Development Technology Group
Summary
This article discusses several ways to use bitmaps in the Microsoft Windows graphics environment, including through simulation and using special drive functions. A small sample application included in Transblt details most of the methods discussed in this article.
Introduction
Using transparent background mode (setting with setBrmode function), an application can use transparent text, transparent lines, and transparent brushes. Sadly, the Microsoft Windows graphics environment does not provide a simple interface for a transparent bitmap. (Yes, it provides, but there is no extensive support for it, just mentioned in "Easy Bitchart Transparency" below. Fortunately, a Bitblt that has a carefully selected raster operation by using a shield bitmap and several times, an application can imitate this effect.
What is a transparent bitmap? It is a bitmap that can be seen from part of its destination file. A simple example is similar to Windows-based images similar to the control panel image. The control panel image itself is basically a rectangle. When it is minimized, the desktop can be seen by this rectangular image bitmap. From an idealized perspective, this image bitmap is designed to grow a square, and some of some pixels are specified as transparent so that those pixels do not block the destination file. Transparent bitmaps can be more interesting by moving, non-rectangular images. The simulation method can be described below can be used to complete these transparency.
symbol
This article uses transparent and opaque these two words to draw pixels in the source position. Transparent pixels are pixels that do not affect the target file. The opaque pixels are pixels that painted on the target file and replaced the original thing in this position.
White and black were assumed to be a value of 1 and all 0. This is correct on all known Windows Display Drivers, including palette devices.
Basic operations involve block delivery from the source file to the target file, additional block transfer related to monochrome mask is also required. Source files and target files are representative of HDCSRC and HDCDest in their device context, or the bitmap can also be the device surface itself. Shielded with HDCMask is assumed to be a monochrome bitmap that is selected to be compatible with DC.
Background concept
We should define and review some basic graphics concepts before discussing the actual transparent imitation.
Grating operation
The last parameter of the Bitblt function specifies a raster operation (ROP) that explicitly defines how to combine the source file, target file, and mode (defined by the currently selected brush brush) to form a target file. Because a bitmap is just a collection of bit values, the raster operation (ROP) is just a Boolean equation that is operated on a bit. The corresponding device, representing different things in the bitmap.
On multi-color devices, each pixel is represented by a bit set, and they either form an index pointing to the color, or directly represent a color. On a monochrome device, each pixel is represented by a bit, 0 means black and 1 represents white.
For all device types, the raster operation (ROP) is simply in the bit display without considering their practical significance.
There is a trick, just combined with a meaningful way. Programmer References in Windows3.1 Software Development Packages, Page 3: Appendix A in the message, structure, and macro lists 256 possible triple grating operations (ROPs). The raster operation (ROP) provides a variety of methods of combining bitmap data, and you can often use not only one method to get the effect you want. This article only discusses four of them.
Pre-defined name Boolean operation transparent simulation Srccopy SRC Directly copy the source to the destination src And DEST varies in the target file to the part of the source file black area, and the portion corresponding to the white area does not move SRCINVERT SRC XOR DEST inserts the source into the target. When used twice, restore the target to its original state. Under certain conditions, you can replace the SrcPaint Src or DEST in this case to brush the non-white area 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 certain grating operations, especially those involved in the target file. Because of this, the skills described in this article are specially displayed and it is possible to work on certain printer devices, such as PostScript printers.
Transparent shield
In this article, "mask" is not something that Batman is wearing a face. It refers to a bitmap that limits the visible parts of other bitmaps. "Mask" has two controls: opaque parts (black), in this partial position diagram is visible and transparent (black), which remains unofficial in this part of the target file. Because "mask" consists of two colors, it can be conveniently represented by a monochrome bitmap, although it can be a black white bitmap. Just as discussed in the "real shielding method" and "Methods to make the source file", data block delivery shield is used as part of the multi-data block transfer process, and its final transparent data of its source bitmap Block delivery sets the target file. The Transblt sample application uses a transparent pigment that is set to 1 and a monochrome shield set to 0 non-transparent pigment. If you need an application to convert these two values, and will supplement some of the monochrome to color transitions in this section.
In addition to providing convenience to transparency, shielding is also useful when imitating complex tailoring operations. This type of tailor cannot be effectively processed in the region of use. The mesh effect transmitted by a shielded data block will cut off part of the source bitmap. For example, only one circular area in the bitmap is displayed, and a shielded shield as the like source file is created and a transparent bit is drawn in the corresponding area. The mechanism to perform this shielded data block will be described in the "real shielding method" and "Method to make the source file".
Monochrome to color conversion
Transparent simulation also involves Windows-based monochrome bitmaps to the conversion mechanism of the color bitmap. vice versa. Windows-based text foreground color and background colors are used to convert between two formats. When the operation is passed on a color target file, a monochrome source bitmap (and / or when a painting is applied) is converted in this bit in this bit in this bit in the actual grating operation (ROP). Background color. Conversely, when the target file is monochrome, Windows converts the colored source into monochrome. In this case, all the pixels consistent with the background colors in the color bitmap becomes 1, and other pixels are converted to 0. Since the examples you want use will use monochrome shields, it is important to set the background color and foreground color before performing block operations.
Performance and screen flashes
The reinforced bitmap operation is slower because of the number of bits that are affected. Moreover, when the screen is directly operated, the flicker is made, making this more serious. When the affected area increases, things will only make worse, although there is no way to improve the speed, but can delete visible flashes by using the shadow bitmap. First, the application copies the screen area to be affected to the storage bitmap, then the application is in the shadow bitmap instead of implementing a bit operation (for example, a transparent effect) on the screen. Finally, the shadow is copied to the screen. The result is only one block passing affects the screen, so it is not possible. Obviously, two additional block operations have caused speed slowing (although the memory block delivery on some devices can pass some of the blocks that have already accessed the screen), but relies on the size and surprised operation of the bitmap. Will feel faster because the flashes disappear. Things are also more clear because there is no chaos flashing. Whether the shadow operation is appropriate depending on the specific needs of the application. Real shielding blocks do not need to make any changes to some parts of the ready-to-use source map. The shielded block passes involves step-by-step operation and shields all transparent elements to 1, so opaque elements are set to 0. Below is the basic code:
// set up destination for monochrome blt (ONLY NEEDED for Monochrome
// mask). THESE ARE THE DEFAULT VALUES AND MAY NOT NEED TO BE
// Changed. The Yy Should Also Be Restore.
SetBkcolor (HDCDest, RGB (255, 255, 255)); // 1s -> 0xffffffff
SetTextColor (HDCDEST, RGB (0, 0, 0)); // 0s -> 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 three steps in the shielded block transfer process are as follows:
The first step (bit block passes with SRCINVERT) is different or to the target file. This looks a bit interesting, but the second step is different or the target file is restored into the original state. Step 2 (Block Transfer with srcand) is a mask operation. When the shield is related to the target file, all transparent pixels do not change the pixels of the target file, and opaque pixels turn directly to black. Now there is an image of an opaque portion of a source file to the outline of the opaque part of the target file, and itself is in the transparent part of the transparent part. The third step (bit block passes with SRCINVERT) is different from the source file or sent to the target file. Transparent pixels are restored into their origin (two steps), and the opaque pixels are copied from the source file.
Unfortunately, when the three steps are executed, the target file does have a slap in which it is quite ugly, and directly on the screen will pass three blocks, it will cause the screen to flash.
Method for making the source file black
As long as you plan to create a source bitmap, the transparent block passes can reduce only two calls. The screen still remains unchanged with the example above, but the source file must be passed in the block of blocking the code like this:
// set Up Destination for Monochrome Blt. Thase Are The Default
// VALUES AND Y NOT NEED TO BE CHANGED. The Yy Should Also Be // Restore.
SetBkcolor (HDCDest, RGB (255, 255, 255)); // 1s -> 0xffffffff
SetTextColor (HDCDEST, RGB (0, 0, 0)); // 0s -> 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);
Shielding the second time to keep the opaque pixel to maintain the remaining unchanged. Then the source file is in the upward, and the target file is now painted on the black part. Because the source file has only black pixels in a transparent place, or the target file remains unchanged in those transparent regions. Note that SRCINVERT POP can replace SrcPaint during the second block to pass the call and achieve a variety of effects. Source shield settings Delete the possibility, this is the only case of xor different from OR.
It is no longer so compelling with this method screen, and once the source file has been set to black, transparency looks very good. 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 bitmap itself. Because bitmaps and icons are as small as, transparency is very smooth.
Bitmap transparency
Bitmap transparency usually refers to a process that removes a bitmap and makes a color in the bitmap to transparent, so that when the bitmap is passed to the screen, the target file can pass. The transparent color of the figure is seen. An application can simulate this operation by constructing a suitable shield and using shielding techniques described in the previous "real shielding method" and "method of making the source file". The following sections describe how to simulate the transparency of the transparency of the display device that cannot perform transparent blocks.
Constructing a monochrome shield from the color bitmap is relatively easy because the built-in color monochrome conversion of the bit block automatically completes all of these work. The goal is that all opaque elements are set to 0 and all transparent elements are set to 1 shield. Setting the background color to transparent color to do this. There is no need to set text foreground color because he cannot use color monochrome conversion (so non-background pigment is set to 0), the following code completed this work:
Setbkcolor (HDCSRC, RGBTRANSPARENT);
Bitblt (HDCmask, 0, 0, DX, DY, HDCSRC, X0, Y0, SRCCOPY);
The code constructs a source file equivalent to a shield of 1 and other places to 0 when transparent colors. This copies the shield used above.
Use shielding
Now is the time when the mask method described above is now used. The real shielding method does not require additional work: create a mask and the source file does not need to be processed. Three block passes indeed caused the screen to flash, but now there is only one one.
On the other hand, the method of turning the source file is required to do some additional work to the source bit map to get the correct input scheme transparent bit needs to be black. Of course, if the transparent color is black at the beginning, the chart is ready to run. On the source file, the transparent pigment is very similar to the expression of opaque pixels on the target document, and it has been used in the use of masking, as shown below:
Setbkcolor (HDCSRC, RGB (0, 0)); // 1s -> Black (0x000000)
SetTextColor (HDCSRC, RGB (255, 255, 255)); // 0s -> White (0xfffff)
Bitblt (HDCSRC, X0, Y0, DX, DY, HDCMASK, 0, 0, SRCAN);
There are now two bit blocks to pass the transparent bit blocks.
Once the reality of transparent block passes, the source bitmap should be restored to its initial color: setBkcolor (HDCSRC, RGBTRANSPARENT); // 1s -> Transparent Color
SetTextColor (HDCSRC, RGB (0,0,0)); // 0s -> Black (0x000000)
Bitblt (HDCSRC, X0, Y0, DX, DY, HDCMASK, 0, 0, SrcPaint);
Because the source bitmap must be changed, then recover, the total number of related bit blocks is 4. This makes the processing slower, but because two of the block passes is performed in the storage bitmap rather than on the screen, it is reduced compared to the real screen method screen. If the source bitmap can keep the transparent bit to be set to black, the two conversion blocks can be avoided together and only two blocks are required for operation; this is in fact an animation is necessary.
Easy bitmap transparency
Some device drivers are directly supported by block delivery. A drive indicates the ability to use CAPSI capabilities to return by a getDevicePaps function. A special background pattern, NewTransparent indicates that the subsequent block passes is transparent block pass. The current background color of the target file is transparent color. When this ability applies to the drive, the basic transparent block passes can be executed according to the following code:
// 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, SRCCPY);
SetBkcolor (HDCDest, RGBBK);
Setbkmode (HDCDest, OldMode);
}
This really makes things simple. Unfortunately, there is currently no more device drivers to support transparent blocks to pass those block passes that are installed with Windows3.1. There is no function. This should change in the future future.
And now, Windows. H does not include definitions of any new variables. Instead, MMSYSTEM is replaced. H file provides definition, this file can be found in the Windows3.1 version of the software development package (SDK).
Transparency with device independent bitmap (DIB)
If the source bitmap is a stand-alone bitmap (DIB) format, the entire shielding process can be used as a source file with a device independent bitmap (DIB). The simple operation of the mask and the color table can be greatly simplified. The processing process is the same as the discussion above, and the processing application can perform all color monochrome and monochrome color conversions by changing the color table, as follows:
SAVE A COPY OF THE.
// 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 is More // Parameters.)
// Now prepare "Blacked Out" Source for the mask blt.
For (Every Color in the color table)
{
IF (color == white) // (White from Above change)
Color = Black;
Else
Color = Original Color from Color Table;
}
// Transparently Blt the Source.
StretchDibits (HDCDest, LPDIB, SrcPaint); // (Yes, There More More More More More More
// parameters.)
// to restore Dib to Original State, Restore Original Color Table. This method needs to be aware of that only one backup of a bitmap is required because it relies on color table conversion to act as a screen and acts as a source file. Regardless of the additional inconvenience that converts the device independent bitmap (DIB) format into equipment dependent format still exists.
