How can I draw a patternBrush with transparent backround (GDI)? - c++

I can't draw a pattern with a transparent background. This is my snippet :
bitmap.CreateBitmap(8, 8, 1, 1, &bits)
brush.CreatePatternBrush(&bitmap)
hbrush = pCgrCurrentDC->SelectObject(&brush);
// set text color
TextCol = pCgrCurrentDC->SetTextColor(CgrColourPalRGB);
int oldBkgrdMode = pCgrCurrentDC->SetBkMode(TRANSPARENT);
//draw polygon
pCgrCurrentDC->Polygon(CgrBuffer, n);
The doc on msdn doesn't mention anything about transparency. I guess this mode could be used? Or is this a bug ?
Thanks!

Mode TRANSPARENT means that background will not be filled before your brush is drawn. But your brush does not contain any transparent pixels in it and it redraws background pixels anyway. Fourth argument in CreateBitmap was set to 1 in your sample. That means bitmap is monochrome.
You need to use 32-bit bitmap to use transparency in brushes. GDI supports transparency with some limits. Use GDI+ for full transparency support.

Related

Transparency issue: SDL_SetTextureBlendMode

I have this PNG file that has a transparent background.
Snippet of transparent background
I set it to surface then to tex :
SDL_Texture* m_Tex = SDL_CreateTextureFromSurface(renderer, surface);
And I want this texture to have a blinking effect so I'm passing it to setTextureBlendMode function
SDL_SetTextureBlendMode(tex, SDL_BLENDMODE_BLEND);
Uint8 m_Alpha = 255;
I will use the m_Alpha for the blinking purpose. I will activate the blinking by pressing a particular button.
And it is working fine. But Why is the background of my texture not transparent anymore after I turn it back to SDL_BLENDMODE_NONE:
SDL_SetTextureBlendMode(tex, SDL_BLENDMODE_NONE);
Snippet of not transparent anymore after BLENDMODE_NONE
Is there a way to make my texture's background transparent again?
I mean, after researching enough, I can't seem to find a way except the SDL_SetColorKey.
But the SDL_SetColorKey needs the loaded surface again. It only means that I will set the PNG file again on surface, then on tex. I think it's not ideal to do this everytime I want the tex to stop blinking. Please help. Thanks.
SDL_SetTextureBlendMode(tex, SDL_BLENDMODE_NONE);
To render textures with Alpha != 1, you will need some blend mode.
In blend mode, you are describing to the system How you want to merge the background color with the foreground color.
You can have a basic idea from this thread.
SDL2: Generate fully transparent texture

Draw/Create ID2D1RenderTarget with Transparent Color

I have a written a class which is able to display animated GIF files with Direct 2d as in this example from MSDN:
https://code.msdn.microsoft.com/windowsapps/Windows-Imaging-Component-65abbc6a/sourcecode?fileId=127204&pathId=969071766
The GIF which I display is a continuously growing/shrinking not filled blue circle. All other pixels are White / the Background is White.
Unlike the example posted I create a CWnd, without Caption and Border, with the size of the GIF, with a ID2D1RenderTarget filling the whole CWnd and place it above the Content of my MainFrame.
Since I never used Direct2d before I assumed I can simply apply SetLayerdWindow() on my CWnd to reach my goal of only displaying the blue Circle.
SetLayeredWindowAttributes(RGB(255,255,255), 204, LWA_ALPHA | LWA_COLORKEY);
This should result in a CWnd with no White Pixels + 80% Transparency. Unfortunately the resulting Window is 80% transparent but none of the WhitePixels where removed/ the white pixels are still drawn.
Why does LWA_COLORKEY not work in this case?
And how can I achieve that either my CWnd or ID2D1HwndRenderTarget will draw white as fully transparent?!
Note:
Besides that I've tried just for fun to draw a fully transparent background with the ID2D1HwndRenderTarget like:
m_pHwndRT->Clear(D2D1::ColorF(D2D1::ColorF::White, 0.0f));
With Microsoft stating: "The alpha value for the color to be constructed. An alpha channel value ranges from 0.0 to 1.0, where 0.0 represents a fully transparent color and 1.0 represents a fully opaque color. The default value is 1.0."
Which results in a fully white opaque window... Which made me wonder if this whole Transparency stuff is working at all

MFC displaying png with transparent background

I need a way to display a PNG image with transparent background on a background with gradient color.
I have tried this:
CImage img;
CBitmap bmp;
img.Load(_T(".\\res\\foo.png"));
bmp.Attach(img.Detach());
CDC dcStatus;
dcStatus.CreateCompatibleDC(&dc);
dcStatus.SelectObject(&bmp);
dcStatus.SetBkColor(TRANSPARENT);
dc.BitBlt(rectText.left + 250, rectText.top, 14, 14, &dcStatus, 0, 0, SRCCOPY);
bmp.DeleteObject();
but foo.png gets black background wherever it is transparent in original image.
I did try to do a new bitmap that was painted with transparent color and did all possible operations on it, but that didn't help. Sample of one permutation:
CImage img;
CBitmap bmp;
img.Load(_T(".\\res\\foo.png"));
bmp.Attach(img.Detach());
CBitmap bmpMaska;
bmpMaska.CreateBitmap(14, 14, 1, 1, NULL);
CDC dcStatus;
dcStatus.CreateCompatibleDC(&dc);
dcStatus.SelectObject(&bmp);
CDC dcMaska;
dcMaska.CreateCompatibleDC(&dc);
dcMaska.SelectObject(&bmpMaska);
dcMaska.SetBkColor(dcStatus.GetPixel(0, 0));
//TODO: Bitmap ni transparent
dc.BitBlt(rectText.left + 250, rectText.top, 14, 14, &dcMaska, 0, 0, SRCCOPY);
dc.BitBlt(rectText.left + 250, rectText.top, 14, 14, &dcStatus, 0, 0, SRCAND);
bmp.DeleteObject();
bmpMaska.DeleteObject();
This did not do the trick. Either, there was all black square on the screen, or the result was the same as original.
I have also checked AlphaBlend API, but my code must be pure MFC + C++ witthout any additional APIs.
[Edit]: Company policy is as little APIs as possible. The code is supposed to run on embedded windows systems in real time.
[Edit 2]: I am not bound to PNG image format, meaning, anything that will display as transparent, goes.
Please, tell me what am I doing wrong?
Convert the png to a 32 bit bmp file. Google 'AlphaConv' and use that. PNG's are a PITA to work with - several API's claim to support them but actually don't, or only partially, or only on some platforms etc.
Load your 32-bit bmp using CBitmap::LoadBitmap (from resources - this is by far the easiest)
Then use CDC::AlphaBlend() to draw your bitmap. TransparentBlt() doesn't work with an alpha channel - it's just either draw the pixel or not. AlphaBlend is part of the win32 API, and you could still investigate CImage::AlphaBlend if you'd like, but that has a bug somewhere (I forgot what exactly) so I always use the raw ::AlphaBlend.
But beware - you need to premultipy the alpha channel for correct display. See my answer on How to draw 32-bit alpha channel bitmaps? .
No variation of what you described will work. You need another API to get this to work. Or, you could use GetDIBits and do your own version of ::AlphaBlend() :)
Based on what you're asking for (simply some set of pixels being transparent) it's probably easiest to use a 24- or 32-bit BMP, and simply pick a color to treat as transparent. Pre-process your picture to take any pixel that precisely matches your transparent color and increase change the least significant bit of one of the channels.
Given 8 bits per channel, this won't normally cause a visible change. Then draw the pixels you want transparent in one exact color. This is easy to do in something like a paint program.
You can then draw that to your DC using TransparentBlt. That lets you specify the color you want to treat as transparent.

ClearType ruins transparency

I have a bitmap which background needs to be replaced with part of another bitmap. Everything works fine until I enable ClearFont on my WindowsXP.
In order to explain my problem better, let us label first bitmap as bmpDestination and second as bmpSource.
Here is how the bmpSource looks like :
Here is how bmpDestination looks like :
When ClearType is off, here is how the correct result looks like :
And here is the incorrect result of their combining when ClearType is on:
ClearType alters some parts of the text background color, so they aren't white anymore ( RGB( 255, 255, 255 ) ) but a combination of white and text color.
I am using BitBlt() and monochrome bitmap to create a mask, and to simulate transparency. I have tried using TransparentBlt() too, but got the same result.
How can I combine bmpSource and bmpDestination, when ClearType is enabled, so I can create correct result like above ?
Thank you for your help.
Best regards.
Render the treeview with black text on a white background. Use a font with grey-scale anti-aliasing. Don't use ClearType anti-aliasing. I'm moderately sure you can achieve this with one of the fdwQuality parameters to CreateFont, but I wouldn't swear to it.
Each pixel will have a shade of grey between white and black. You can interpret this as transparency. White is fully transparent; black is fully opaque. Use this information to create a bitmap with transparency. Render this transparent bitmap over your multi-coloured background.

Why would GDI+ colours vary based off whether a tooltip is visible?

I'm displaying a bitmap using GDI+. After loading the bitmap from a DLL resource I set the background colour (blue - #0000FF) to transparent using TransparentBlt. On Windows Vista and later this works as expected.
However, on a Windows XP system we're testing on this only works when any tooltip (e.g. the "title" property in IE, or Windows Explorer's tooltip shown when hovering the mouse over a file, etc) is displayed. The rest of the time the background colour is still blue.
Has anyone encountered this before, or know of a way to stop this occurring and for the blue to be properly made transparent?
Edit: After further investigation I found that setting colour depth in Windows XP to 16 bit colours instead of 32 bit colours caused TransparentBlt to start working normally again. Obviously this isn't an ideal solution, specifying what colour depth must be used, but does this give any hint to what might be happening?
Edit2: Code sample included.
m_pGDIBitmap = new Gdiplus::Bitmap(_Module.m_hInst, MAKEINTRESOURCE(lImageResource));
m_hMemDC = CreateCompatibleDC(hdc);
Gdiplus::Graphics myGraphics(m_hMemDC);
myGraphics.DrawImage(m_pGDIBitmap,
Gdiplus::Rect(0, 0, m_pGDIBitmap->GetWidth(), m_pGDIBitmap->GetHeight()),
0,
0,
m_pGDIBitmap->GetWidth(),
m_pGDIBitmap->GetHeight(),
Gdiplus::UnitPixel, &imAtt);
SetStretchBltMode(hdc, HALFTONE);
SetBrushOrgEx(hdc, rcBounds.left, rcBounds.top, NULL);
TransparentBlt(hdc, rcBounds.left, rcBounds.top, iScaledWidth, iScaledHeight, m_hMemDC, 0, 0, iBitmapWidth, iBitmapHeight, GetPixel(m_hMemDC, 0, 0));
You must show some sample code - the code that loads the bitmap and the code that blits it to display.
From the symptoms that you describe, my guess is that you load the bitmap not in its native format, but in the current display format. This means, that when the bit depth of the bitmap differs from the bit depth of the display, an automatic color space conversion is made. When this happens, the color that you provide to TransparentBlt is actually different from the color in the bitmap.
Possible alternative solutions:
Make sure that the bitmap is loaded in its native format without conversion.
Allow the conversion to take place, but instead of providing a hardcoded color value to TransparentBlt, make a GetPixel of a known "transparent" pixel of the bitmap (like top-left), and provide this value to the TransparentBlt.
What I ended up doing was more of a workaround, but it did work. I changed the background colour to black and added the following code before the DrawImage call:
Gdiplus::ImageAttributes imAtt;
imAtt.SetColorKey(Gdiplus::Color(0, 0, 0), Gdiplus::Color(0, 0, 0), Gdiplus::ColorAdjustTypeBitmap);
For some reason using this with blue as the background didn't work and using TransparentBlt on its own with either colour didn't work, but the combination applied the transparency correctly on the various OSes and colour depths that I tried.
If I had access to a paint program that supported bitmap files with an alpha channel, i.e. 32 bit bitmaps, I suspect making the background explicitly transparent and then using AlphaBlend would have worked as well but I didn't have the ability to try that at the time.