asked on

Are there any known memory leaks with StretchBlt and BitBlt

I have a pretty straightforward bit of code that that uses two CDCs to paste an HBITMAP into a larger HBITMAP at a specified rect. The code works, but I was noticing a memory leak as the stitching was happening.

When I first create the larger HBITMAP, I see the Virtual Memory usage in my task manager increase by the size of the bitmap, as I would expect. Correct me if I'm wrong, but when I then bit blit data into an area of that large HBITMAP, the "Mem Usage" column in the task manager should not necessarilly increase, correct?

When I commented out the StretchBlt line and let everything run, both the VM Size and Mem Usage values in the task manager remained the same. Allowing the StretchBlt to happen, and the Mem Usage column kept increasing, while VM Size stayed the same.

I use StretchBlt because my code is used both when I'm pasting a smaller image into a bigger image and when I"m pasting a bigger image into a smaller image, but in this case, I tried using BitBlt as well, and saw the same increase in Mem Usage.

Is there a problem with my code? I don't understand why performing a StretchBlt (or BitBlt) would cause the memory used to increase.

thanks

-------------------------------------
CRect pasteRect;
GetRectAtIndex(a_iIndex, &pasteRect); // returns a 1000x1000 rect

CDC memDCImage, memDCThumbs;

memDCImage.CreateCompatibleDC(NULL);
memDCThumbs.CreateCompatibleDC(NULL);

BITMAP bmp;
::GetObject(a_hbmImage,sizeof(BITMAP),&bmp);

HBITMAP hbmOldImage = (HBITMAP)memDCImage.SelectObject(a_hbmImage);
HBITMAP hbmOldThumb = (HBITMAP)memDCThumbs.SelectObject(m_hbmThumbnailSurface);

memDCThumbs.SetStretchBltMode(HALFTONE);
memDCThumbs.StretchBlt(pasteRect.left, pasteRect.top, pasteRect.Width(), pasteRect.Height(), &memDCImage, 0, 0, bmp.bmWidth, bmp.bmHeight, SRCCOPY);

memDCThumbs.SelectObject(hbmOldThumb);
memDCImage.SelectObject(hbmOldImage);

DeleteObject(hbmOldImage);
DeleteObject(hbmOldThumb);

memDCImage.DeleteDC();
memDCThumbs.DeleteDC();
-------------------------------------

DanRollins

What APIs are you using to create the HBITMAP. It is perfectly possible that those steps just cause the system to allocate memory and that no physical memory would be accessed until such time as you "touch" the data.

I'll bet that you can see a similar jump in physical memory usage if you even use SetPixel -- anything that actually changes a value in the allocated memory -- including directly accessing it via its lpBits or SetDIBits() ... It might also jump if you use GetDIBits() since I'd assume that would cause the memory are to be locksed and thus forcing a change from virtual to physical.

-- Dan

PMH4514

ASKER

Dan -
I create them using CreateDIBSection

I understand what you're saying, but in some instances, when the HBITMAP is created, I may see an increase in used Virtual Memory by upwards or 400MB depending on the size of the large image into which my sub-images are stitchec. My System Ram usage may start off around, oh say 20MB, but as the map is built, the system comes to a hault as the Mem Usage goes approaches the amount of physical RAM on the system. If ~500MB of virtual ram were allocated for an HBITMAP that required 500MB, I don't understand why filling that space up would cause such a dramatic increase in used physical ram.

And if that is normal operation, how do I alleviate the problem?

ASKER CERTIFIED SOLUTION

DanRollins

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

AndyAinscow

Minor point.
A memory leak is typically assigning a block of memory with new, but later not freeing it with delete. In DEBUG mode the IDE will give warnings when the app is closed.

PMH4514

ASKER

right Andy, I did hesitate to use the term memory leak here, because the IDE wasn't giving such warnings. Perhaps what I'm seeing is in fact normal functionality as Dan is implying.

DanRollins

It's a longshot, but it might be worth testing to see if the HALFTONE adjustment logic for your device driver is causing the extra memory to be allocated "behind the scenes". Just comment out the line...
memDCThumbs.SetStretchBltMode(HALFTONE);
ans see if the behavior changes.

PMH4514

ASKER

yah no effect. I had tried various blt modes, including no specification, still see the same thing.

'course this may become moot with the code from my other question you've been helping with