We're currently shifting an older application to draw through GDI+, instead of using GDI directly. As we are progressively translating teh system as we go, sometimes we need to grab a HDC from a Gdiplus::Graphics object in order to allow code which hasn't been translated yet to draw straight to it using GDI.
The drawing happens fine, except we seem to be losing antialias on images drawn directly to the DC using GDI. If, after grabbing the DC from the Graphics object, we draw a filled rectangle over the entire area, and then proceed with the drawing, it comes out fine. If we just get straight to drawing everything comes in without antialias.
void Draw(Gdiplus::Graphics& renderContext)
{
auto hdc = renderContext.GetHDC();
auto dc = HDC::FromHandle(nativeDC);
//Required to antialias drawing below
dc->FillSolidRect(GetClientRect(), RGB(255, 255, 255));
/* Do Drawing */
dc ->Detach();
renderContext.ReleaseHDC(hdc );
}
To be more precise, it seems like the antialias alpha get's flattened, which explains why filling a rectangle in GDI before drawing removes the artifacts.
It's a similar effect you might get if you draw with antialias on onto one Bitmap, and then try to alphablend it on top of another Bitmap - the alpha information on the top gets flattened and then the new alpha value specified in a ColorMatrix is applied to the whole image.
If anyone could provide some insight into what exactly is going on when you grab/release a HDC from a graphics object, and why drawing with GDI directly looses the alpha, I'd be appreciated.
The bitmap backing the HDC is a copy, not the original, as described here.
Using GDI on a GDI+ Graphics Object Backed by a Bitmap
When Graphics::GetHDC() is called for a Graphics object that is backed
by a bitmap rather than the screen, a memory HDC is created and a new
HBITMAP is created and selected into the memory HDC. This new memory
bitmap is not initialized with the original bitmap's image but rather
with a sentinel pattern, which allows GDI+ to track changes to the
bitmap. Any changes that are made to the memory bitmap through the use
of GDI code become apparent in changes to the sentinel pattern. When
Graphics::ReleaseHDC() is called, those changes are copied back to the
original bitmap... Also, there is a performance cost to this approach because
GDI+ must copy the changes back to the original bitmap.
Obviously when you draw on an HDC with GDI you won't get any antialiasing. GDI doesn't support it. That's what GDI+ is for.
Related
I've inherited a project which renders a 3D scene directly to the window using OpenGL. The code works fine, but we're now drawing an icon onto the 3D view to "Exit 3D view mode". This also works fine, but results in a lot of flickering as the view is rapidly rotated.
I'd like to be able to draw to an off-screen bitmap (ie. without a HWND), then draw my icon to the bitmap, then finally StretchBlt the bitmap to the window using double-buffering. We do this in other contexts (such as zooming into an image which does not need OpenGL) and it works great. My problem is that I am an OpenGL novice and all attempts at starting with the DC of the off-screen bitmap and creating a HWND from this DC fail, usually because of selecting a pixel format for the DC.
There are a few questions asking similar things here on StackOverflow (eg. this question without an accepted answer. Is this possible ? If so is there a relatively straightforward tutorial describing the procedure? If the process is extremely complex requiring detailed OpenGL knowledge, then I may just have to leave it and live with the flickering because it is a rarely used mode in our software.
Just draw the Icon using OpenGL using a textured quad.
All this draw to a bitmap copy to DC StretchBlt involves several roundtrips from and to graphics memory (wastes bandwidth) and StretchBlt will likely not be GPU accelerated. All in all what you want to do is inefficient and may even reduce quality.
I presume you have the icon stored in your executable as a resource. The most simple way to go about it is to create a memory DC (CreateCompatibleDC) with a DIBSECTION (CreateDIBSection), draw the icon to that and load the DIBSECTION data into a OpenGL texture. Then to draw the icon use glViewport to select the destination rectangle in window coordinates, use an identity transform to draw a rectangle covering the whole viewport (position values (-1,1)→(1,1), texture coordinate values (0,0)→(1,1) gives you the right outcome).
Important side fix: In case your program does silly things like setting viewport and the fixed function pipeline GL_PROJECTION matrix in a window resize handler you should clean up that anti pattern and move this to where it belongs: In the drawing code.
I'm not exactly a windows programming expert ;) so please excuse me if this question is trivial.
I have a window on which I want to display a bitmap. The bitmap can be either stretched to span over the whole area or it will be displayed with original aspect ratio and empty space will be filled with a solid brush.
I load the bitmap with LoadImage and display it using BitBlt. I do it on WM_ERASEBKGND, I use the DC from wparam which is a mem DC.
I was thinking of using StretchBlt instead of BitBlt when the bitmap needs to be stretched.
So my questions are:
is it okay to store a bitmap as HBITMAP or should I use DIBSection? Which one is better performance-wise, what's the memory footprint of both solutions?
should I always stretch the bitmap when drawing to a DC on WM_ERASEBKGND, or should I create a compatible DC (or bitmap) with a precomputed stretched bitmap and then just BitBlt it to the target DC?
if I create a precomputed bitmap, should I immediately unload the original bitmap to save on memory?
should I use BitBlt/StretchBlt or CopyImage?
I read that I can also use LoadImage with desired width and height parameter, so that the loaded image is already stretched, is this solution better?
I'd be really grateful for some code examples.
Edit:
GDI+ solutions are welcome too. I'm interested in the best, easiest and best-performing solution for this problem.
I'm wondering , if I want to create different bitmaps,
I use the CreateCompatibleBitmap function again and again, to associate it to the same memory CDC.
is it the same meaning that I CreateBitmap and SelectObject again and again??
I ask this question because I want to do something to the newly created bitmap by another CDC.
Without seeing the specific code it's hard to know the exact problem but CreateCompatibleBitmap is commonly used in double-buffering situations to avoid flickering. Rather than drawing directly to the Device Context (DC) you first draw to an off-screen, or memory, DC which is basically drawing to a bitmap. The bitmap is then copied directly to the screen DC using BitBlt, so it appears like all the drawing happens at the same time.
The usual steps are this (and will probably happen on every WM_PAINT):
Use the screen DC to create a bitmap, which is 'compatible' with it, using CreateCompatibleBitmap.
Create a memory DC
Select the bitmap into the memory DC (this is what you'll draw to)
When drawing is finished BitBlt the memory DC's bitmap onto the screen DC.
More information available here: Guide to Win32 Memory DC (Code Project)
Yes, CreateCompatibleBitmap() creates a new bitmap, a new memory allocation, a new handler each time you call it in a loop;
I have a visual C++ application that uses a CView derived class to render its display, which is primarily 3d vector data and true type text. The mapping mode used is either MM_ANISOTROPIC or MM_LOMETRIC. I can't use MM_TEXT as I use the same code for printing and plotting of the data and also have to overcome non-square screen pixel issues.
The drawing code currently draws directly onto the screen using the CViews OnDraw method and the CDC object provided. I am trying to replace this with drawing to a bitmap and blitting the bitmap to screen, using a CreateCompatibleDC / CreateCompatibleBitmap combination, as described in the MS documentation and elsewhere.
The problem is that the DCs are not compatible for mapping modes other than MM_TEXT, such that my view is rendered upside down and at the wrong scale. Investigation shows the following;
void CMyView::OnDraw(CDC *pDC)
{
CDC MyDC = CreateCompatibleDC(pDC); // Create a new memory DC;
int a = pDC->GetMapMode(),b = MyDC.GetMapMode();
'
'
'
}
a = 2
b = 1
Calling a SetMapMode on MyDC causes the display to be drawn entirely in black. Do I have to rewrite my code to suit MM_TEXT for drawing to a bitmap, or is there another way to overcome this problem.
You probably need to also call SetWindowExt and SetViewportExt. I have definitely used MM_ISOTROPIC with bitmap DCs before and it worked OK (don't have the code to hand as it was since ported to GDI+)
How to Convert a Bitmap-like struct into an HDC?
I am now writting image processing program in c++, gdi.
If I got a HDC.
I can draw whatever I like on the HDC in gdi by the following code.
// HDC is handy.
HDC dc;
dc.DrawXXX // I can draw using gdi method.
Graphics gr(dc); // now I can also draw on the dc using gdi+ method.
My Application is based on FreeImage.
I make of fipImage. ( use data struct like Bitmap )
However if I want to draw on fipWinImage, now I have to copy fipWinImageto Bitmap, then draw on the Bitmap, and finally convert the bitmap into fipImage again, which is time comsuming and memory comsuming.
Convert fipImage to Bitmap -> Draw on the bitmap -> convert bitmap to fipWinImage
fipWinImage imagefip;
Bitmap* tempImg = new Bitmap(imagefip->GetWidth(), imagefip.GetHeigt(), PixelFormat24bppRGB); // memory comsuming is image is large
Graphics *pGr = Graphics::FromImage(tempImg);
HDC dc = pGr->GetHDC();
RECT rec;
rec.left = 0;
rec.top = 0;
rec.right = imagefip.GetWidth();
rec.bottom = imagefip.GetHeight();
fipImage.draw(dc, rec); // using stretchdibits()
pGr->ReleaseHDC(dc);
Graphics gr(tempImg);
HDC dc = gr.GetHDC(); // Get an Hdc, draw using gdi method
gr.ReleaseHDC(tempDC); //
gr.drawXXX // Draw using gdi+ method.
fipWinImage fipImg; // final result fipWinImage.
HBITMAP temp;
Color color;
tempImg->GetHBITMAP(color, &temp);
fipImg->copyFromBitmap(temp);
I want to construct a HDC directly from fipImage. and draw directly on fipWinImage
How can I do this?
First a few clarifications:
A Device Context is basically a structure that remembers things like foreground and background colors, brushes, font info, and the physical drawing surface (bitmap).
This is a handy thing, so that you don't have to keep specifying all of these things when you're doing one graphics operation after another. You can also pass all of these settings around more easily this way. That's all that a DC really is - just a collection of drawing parameters, including the surface to draw upon.
An "HDC" is just a handle (reference) to one of these structs. Being a "Handle" lets window move the struct around in memory to manage free space without your pointers to it getting messed up.
If you have access to the source code for the library you're using, examine the fipWinImage::draw(...) method. If they're using StretchDIBits, then they must get their raw bitmap data into a compatible format at some point. It's also possible that the fipWinImage class is wrapping an underlying BITMAP or DIB, etc.
The final step to getting your own HDC...
A bitmap is "SELECTED" into a device context, and can only be selected into a single DC at one time. If you can get the internal HBITMAP from fipWinImage, you can select it into another DC (assuming that it isn't still selected into another HC).
When you create a DC, windows automatically creates a 1x1 bitmap for it (since a DC must have a selected bitmap at all times). When you select in a new bitmap, you get the handle to the previously selected bitmap returned to you. Hang on to that, because you're going to need to put it back when you're done.
Hope that helps.
I don't know FreeImage, but if you can get a pointer to the actual pixel data (DIB section) out of it, you could just create a HBITMAP that shares it without having to copy the data every time.