Using the AlphaBlend function

Sample Image - alphablend.gif

Note: The code in this article is restricted to win98 and win2000

Do you want to cool splash window?. Do you think the general splash window is not good enough for your app? Then this sample source is for you.

My semi-transparent splash window uses the AlphaBlend function. When I found this function, I was so surprised! The function works just like BitBlt for bitmaps that have transparent or semitransparent pixels. Here is the AlphaBlend function's syntax

BOOL AlphaBlend( HDC hdcDest,
  int nXOriginDest,
  int nYOriginDest,
  int nWidthDest,
  int nHeightDest,
  HDC hdcSrc,
  int nXOriginSrc,
  int nYOriginSrc,
  int nWidthSrc,
  int nHeightSrc,
  BLENDFUNCTION blendFunction
);

The important parameter is last one, BLENDFUNCTION.

typedef struct _BLENDFUNCTION {
    BYTE     BlendOp;
    BYTE     BlendFlags;
    BYTE     SourceConstantAlpha;
    BYTE     AlphaFormat;
}BLENDFUNCTION;

BlendOp must be AC_SRC_OVER
BlendFlags must be 0
SourceConstantAlpha must be between 0 (transparent) and 255 (semi-transparent).
AlphaFormat must be AC_SRC_ALPHA

MSND states: The SourceConstantaAlpha member of BLENDFUNCTION specifies an alpha transparancy value to be used on the entire source bitmap. The SourceConstantAlpha value is combined with any per-pixel alpha values. If you set SourceConstantAlpha to 0, it is assumed that your image is transparent. Set the SourceConstantAlpha value to 255 (indicates that the image is opaque) when you only want to use per-pixel alpha values.

See the sample application for a demonstration.

Just enjoy!!

Ajou University C.C. 4th member.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

Wooseok Seo

Software Developer (Senior)

Korea (Republic Of)

Member

Woo Seok Seo have been a Microsoft MVP for 7 years and have translated several books into Korean. Author of C# Programming for Beginner (DevPress, 2001), he is interested in Debugging techniques and .NET technology. Get in touch with Woo Seok Seo at wooseok.seo@gmail.com

Article Top

Poor

Excellent

Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

You must Sign In to use this message board. (secure sign-in)

Search this forum
	Profile popups Noise Layout Per page

My vote of 3

Mahdi Nejadsahebi

21:24 30 Apr '11

it's good and usefull
Sign In·View Thread·Permalink

My vote of 2

Member 318684

0:41 6 Jan '10

Only a copy of MSDN manual
Sign In·View Thread·Permalink

AlphaBlend draws over the existing backgruound making it darker. gradually losing transaprency

VC++Maniac

21:15 20 Apr '09

AlphaBlend function draws over the existing background. I return FALSE in OnEraseBkGrnd(). Still it does not erase the background. Gradually losing its transparency.
here is the code:

BLENDFUNCTION bfn;
	bfn.BlendOp = AC_SRC_OVER;
	bfn.BlendFlags = 0;
	bfn.SourceConstantAlpha = 100;
	bfn.AlphaFormat = AC_SRC_ALPHA;
	
	pCdc->AlphaBlend(0, 0, rc1.Width(), rc1.Height(), &memCDC, 0, 0, rc1.Width(), rc1.Height(), bfn);

About OnPaint with the AlphaBlend(); [modified]

Ted Lin

22:12 16 Aug '07

Dear Sir,

I modify your sample code to let the form can be moved.
I set the fix value like "SourceConstantAlpha = 185";
And set the bitmap with all dark.
I run the sample, the graphic is always dark.

I think the CClientDC is not release completed, and the next paint is coming.
I research the CClientDC, the document said it will destory automatically.
But the program run is wrong.

Do you have any idea to fix this problem? Smile | :)

Thanks.

-- modified at 4:20 Friday 17th August, 2007

AlphaBlend wrong formula ?!

Octopod

10:17 23 Sep '06

Hi fellow coders,

When I'm blending pixels ARGB 127,127,127,127 on pixel RGB 0,0,127 the result is surprisingly RGB 127,127,190 !! where I was waiting for a result of 63,63,127.

AlphaBlend is using the formula :
A1R1G1B1 blended on R2G2B2 = ( R1 + A1*R2 ), ( G1 + A1*G2 ), ( B1 + A1*B2 )

How can I have it working with the formula :
A1R1G1B1 blended on R2G2B2 = ( A1*R1 + (255-A1)*R2 ), ( A1*G1 + (255-A1)*G2 ), ( A1*B1 + (255-A1)*B2 )

I'm using the following code :

CImage MyImage;

CClientDC dc ( MyMFCControl );

_pDoubleBufferBitmap = new CBitmap();

_pDoubleBufferBitmap -> CreateCompatibleBitmap ( &dc, ... );

_pDoubleBufferCDC = new CDC();

_pDoubleBufferCDC -> CreateCompatibleDC(&dc);

_pDoubleBufferCDC -> SelectObject(_pDoubleBufferBitmap);

CPaintDC* pPaintDC = CreateCompatibleDC ( dc );

MyImage.AlphaBlend ( _pPaintDC -> m_hDC, 50,50, 0xFF, AC_SRC_OVER );

Thank you for any help..

Alexis.

Re: AlphaBlend wrong formula ?!

Octopod

10:50 23 Sep '06

Oh.. ok I got it now. The MSDN was not clear enough for me about the need of an alpha pre multiplyed ARGB format . Alexis.
Sign In·View Thread·Permalink	2.00/5 (1 vote)

Thank you

Nick Z.

10:41 23 May '05

I translated this into C#. Works like a charm! Infinitely faster than DrawImage and the like in .NET. I simply didnt know about this function. Thanks for pointing it out!
Sign In·View Thread·Permalink	2.00/5 (1 vote)

Problem with AlphaBlend

acidutzu

23:13 23 Mar '05

Hi.
I have a problem with the AlphaBlend function, that is the rendered bitmap doesn't look like it should.
For example, a bitmap with a pure red opaque region (a = 255, r = 255, g = 0, b = 0) and transparent in rest looks very weird: on a white background it's completly transparent, on a blue background the red region is magenta, etc. It looks like the Alphablend adds with saturation the coresponding channels of the colors.
The bitmap is obtained from a tiff image, edited with Photoshop.
Here is a part of the source code:

//premultiply the pixels of the bitmap
for (int i = 0; i < m_bm.Width(); i++)
{
for(int j = 0; j < m_bm.Height(); j++)
{
GX_RGBA c = m_bm.ReadPixel(i, j);
c.r = (BYTE)((double)c.r * c.a / 255.);
c.g = (BYTE)((double)c.g * c.a / 255.);
c.b = (BYTE)((double)c.b * c.a / 255.);
m_bm.WritePixel(i, j, c);
}
}

//call AlphaBlend
CDC memDC;
memDC.CreateCompatibleDC(NULL);
CBitmap *oldBmp = memDC.SelectObject(CBitmap::FromHandle(hBmp));
if (pBm->Type() == colour32)
{
BLENDFUNCTION bld;
bld.BlendOp = AC_SRC_OVER;
bld.BlendFlags = 0;
bld.SourceConstantAlpha = 255;
bld.AlphaFormat = AC_SRC_ALPHA;
AlphaBlend(*dp.pDC, outputOrigin.x, outputOrigin.y, m_bitmap.Width(), m_bitmap.Height(), memDC, 0, 0, m_bitmap.Width(), m_bitmap.Height(), bld);
}

Any insights will be very appreciated, thank you.

/\

Re: Problem with AlphaBlend

jgarnett

15:59 27 Oct '05

Hey, Try this if you haven't already figured it out: bld.AlphaFormat = 0; I had the same problem and setting bld.AlphaFormat to 0 seemed to fix it.
Sign In·View Thread·Permalink

Question

one_eddie

11:40 1 Oct '04

Can i draw with a single call of AlphaBlend image with alpha and transparency or should I call TransparentBlt and then AlphaBlend? If the first one is true, please show me a sample code
Sign In·View Thread·Permalink	1.00/5 (1 vote)

Great stuff!

JustDan

17:36 24 Jan '04

I've been looking all over the Internet for an explanation of this and this is the only article. Thank you Woo Seok Seo!
Sign In·View Thread·Permalink

Re: Great stuff!

anothermxw

19:08 4 Apr '04

really? i have seen several AlphaBlend?
Sign In·View Thread·Permalink

Re: Great stuff!

Anonymous

14:18 5 Apr '04

Oh, well, I didn't find it and it doesn't diminish how awesome this article was!
Sign In·View Thread·Permalink

No with Dialog

mojster

5:42 17 May '03

Where can I find the same demo but I want that it is normal window???
Sign In·View Thread·Permalink

Algorithm Code

Jack Rabbit

17:34 27 Feb '03

You can find code for the alphablend algorithm that will run on Windows 95 here: http://www.windevnet.com/documents/s=7628/wdj0109b/0109b.htm
Sign In·View Thread·Permalink

Re: Algorithm Code

Henry P.

17:57 27 Feb '03

Unfortunately, that algorithm is not nearly as fast as the Windows one, which probably is written in assembly.

I'm actually looking for an alpha-blending algorithm to be used in a moderately intensive graphics application involving lots of animation, an algorithm that's fast and works with all versions of Windows, msimg32.dll is probably the best bet but I'm not completely certain that it could be used with Win95/NT. Would appreciate any info from someone who has tested it with those OS's.

Henry P.
http://www.allersoft.com

Re: Algorithm Code

Jack Rabbit

19:38 28 Feb '03

How much slower is it?

On my machine, the code is actually faster. (I must be doing something wrong)

I'm using DoAlphaBlend for XP menu, toolbar effects and for "softening" lines and text in the main view of the program. I took a little shortcut in Christian's algorithm: Since I know the background (destination) is always the same colour (i.e. all bits the same RGB value), why bother creating 2 DIBs? I simply create 1 DIB in the algorithm, and then apply the alphablend between the source DIB bits and a static background colour.

I also ignore any source bit that is the same colour as the background color. This acts like a transparency for background coloured bits in the source.

Re: Algorithm Code

Anonymous

6:27 3 Mar '03

Actually, the Windows AlphaBlend function has variable speeds depending on the specific parameters it's given. If you blend two bitmaps that are compatible with each other, it is MUCH faster than blending two bitmaps that are incompatible. For instance, if you're trying to blend a 24-bit bitmap to a 16-bit surface, it's a lot slower than blending a 16-bit bitmap to a 16-bit surface.

This difference is probably insignificant when you're dealing with bitmaps of menu size. However, when you're blending a bitmap, measuring say 800x600 pixels, that's almost half a million pixels that you have to compute the composite color for. That is too slow on most current home computers to be of use in an animation application.

I've found that blending two compatible bitmaps using the Windows AlphaBlend is amazingly fast, whereas blending two incompatible bitmaps (say a 32-bit DIB with a 16-bit surface) is MUCH slower (perhaps by an order of magnitude?).

Incidentally, if you include the msimg32.dll from WinME (and probably 98 as well) - but not the one from Win2000/XP - the AlphaBlend function will work on Win NT4. I haven't tested it on a Win95 machine yet (hard to find one these days) but I think it should work well as well (When you examine the import table for the WinME msimg32.dll, it contains only function calls to "basic" GDI functions that are available on all Windows platforms, so it probably will work on all Windows platform).

Re: Algorithm Code

Jack Rabbit

4:50 8 Mar '03

For the testing, I'm using the AlphaBlend on the entire view of an SDI project. (1280 x 1024, minus scrollbar space)

Here's the code I'm using in my OnDraw function.

CDC memDC;
memDC.CreateCompatibleDC(pDC);

CRect rcClient;
GetClientRect(&rcClient);

CBitmap bmp;
bmp.CreateCompatibleBitmap(pDC, rcClient.Width(), rcClient.Height());

CBitmap* pOldBmp = memDC.SelectObject(&bmp);

memDC.FillSolidRect(&rcClient, GetSysColor(COLOR_WINDOW));

BLENDFUNCTION bf =
{
AC_SRC_OVER,
0,
170,
0
};

// Output text and lines here.

// Perform the blend
AlphaBlend(pDC->GetSafeHdc(), rcClient.left, rcClient.top, rcClient.Width(), rcClient.Height(), memDC.GetSafeHdc(), rcClient.left, rcClient.top, rcClient.Width(), rcClient.Height(), bf);

memDC.SelectObject(pOldBmp);

Am I doing something that is not optimal for the SDK based function? Christian's algorithm, combined with the tweaks I mentioned in a previous article, result in roughly 3x faster drawing code.

Re: Algorithm Code

Henry P.

19:22 31 Mar '03

I've created an SDI project, and paste the code you provide into the CMyView::OnDraw function. I changed the color of the memDC to red to make the painting more easily observable. I did not do a formal timing test, but by resizing the view, the repainting occurs much quicker with the Windows AlphaBlend as compared to Christian's AlphaBlendU. The former repainting is almost instanstaneous whereas the latter pauses (the background takes on the original white color for a split second) before the painting is completed.

This test was done on a AMD 1.8GHz with WindowsXP, 512MB RAM. This could be a system-specific finding.

The Windows AlphaBlend function actually allows two different blending modes, by specifying the last parameter (AlphaFormat) of the BLENDFUNCTION struct. For reference:

typedef struct _BLENDFUNCTION
{
BYTE BlendOp;
BYTE BlendFlags;
BYTE SourceConstantAlpha;
BYTE AlphaFormat;
}BLENDFUNCTION, *PBLENDFUNCTION, *LPBLENDFUNCTION;

If AlphaFormat is 0, the source image is assumed to have a constant alpha as specified by SourceConstantAlpha. If AlphaFormat is AC_SRC_ALPHA, the source image is assumed to contain individual alpha values for each pixel (the alpha value being contained in the fourth byte of each pixel in a 32-bit (4 bytes per pixel) bitmap.

The reason I bring this up is because I've found that, at least for several computer systems I've tried on (both AMD, WinXP and Win2000), the blending is SIGNIFICANTLY faster when AlphaFormat is 0 (comparable to a BitBlt of the same bitmap size), whereas when the AlphaFormat is AC_SRC_ALPHA, the speed is slower, comparable to Christian's algorithm.

My speculation is that for the case where AlphaFormat is 0 (i.e., only a single SourceConstantAlpha is used), the Windows function does not need to extract the device-independent bits, and rather operate directly on the device-dependent bitmaps. The Windows function may also take advantage of driver acceleration as well...but this is just speculation.

If anyone discovers other interesting findings, please post them here.

Henry P.
http://www.allersoft.com

Re: Algorithm Code

B2kguga

10:04 25 Feb '07

Hi guys someone have a working version of this algo ? I tried it, but got nothing
Sign In·View Thread·Permalink

Win95/98/ME vs. WinNT/2000/XP

Henry P.

16:57 27 Feb '03

The msimg32.dll is required for AlphaBlend to work. It's not included, however, for Win95 and NT...This file is substantially different between the two families of Windows operating systems. For the 98/ME line, the file is about 50 KB in size whereas it's only 5 KB for the 2000/XP line. The reason is that the 98/ME file actually CONTAINS the drawing code for the alpha blending, whereas the 2000/XP file is merely a wrapper dll that will call the actual alpha blending function (named gdiAlphaBlend) in gdi32.dll. This can be verified by looking at the import tables for the two files.

Anyway, this means that the 2000/XP msimg32.dll may not be usuable on an NT4 platform, since the NT4 gdi32.dll may not contain the gdiAlphaBlend function. So if you want to use AlphaBlend on NT4 you might actually need the msimg32.dll from the 98/ME line.

Hope this makes sense.

Henry P.
http://www.allersoft.com

Re: Win95/98/ME vs. WinNT/2000/XP

Christian Graus

17:57 27 Feb '03

On the other hand, WDJ has code on thier site from an article I wrote that offers alphablending for all Windows versions. Christian NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma
Sign In·View Thread·Permalink	2.00/5 (1 vote)

Re: Win95/98/ME vs. WinNT/2000/XP

Henry P.

9:21 3 Mar '03

Thanks for the link...I'll attempt a thorough comparison between your algorithm and the Windows function in terms of speed. Just a quick comment, looking at your code it seems that it does not currently support variable source alpha (i.e., alpha values that are different for the individual source pixels), but it could probably be modified quite simply to handle this case.

Henry P.
http://www.allersoft.com

Re: Win95/98/ME vs. WinNT/2000/XP

Christian Graus

9:29 3 Mar '03

Yes, you are right. My algorithm seeks simply to copy the windows one, but it would be quite effortless to generate varying alpha based on a mask image or an algorithm. Christian NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma
Sign In·View Thread·Permalink