0
votes

I am writing program in c++ gdi gdi+. Drawing large image on gdi+ bitmap is slow is using gdi+ api. So I used the following way to draw:

Bitmap img(xxx);
Graphics gr(&img);
HDC dc = gr.GetHDC();
::StretchDIBits( 
    dc,
    rec.left, rec.top, 
    (rec.right - rec.left), (rec.bottom - rec.top),
    m_recRegin.left , m_recRegin.top,
    m_recRegin.right - m_recRegin.left, m_recRegin.bottom - m_recRegin.top,
    XXX, XXX, DIB_RGB_COLORS, SRCCOPY);
gr.ReleaseHDC(dc);

this code run perfectly some time. But when the system-wide pool is full by creating lots of compatibleDCs with large size of CBitmap. It seems can not draw any thing on the Bitmap.

What happened? when this part of code failed, I can still draw on the graphics using GDI+ APIs

GetLastError() return 8.

Many thanks!

2
Update us with the value returned by the GetLastError() after the call to StretchDIBits() failed please.arul

2 Answers

1
votes

GetLastError() return 8

8 is "Not enough storage is available to process this command."

So you ran out of storage for GDI to use to execute ::StretchDIBits.

In the future, you can lookup Windows errors from the command line with: net helpmsg <error in decimal>.

0
votes

In addition to what others have said, Graphics objects implement IDisposable. This means they likely (and actually do) hold onto a limited resource. Ensure you are calling "gr.Dispose()" or placing things in a "using" block. Failing to do this will leave it up to the garbage collector to determine when the objects are finalized, and their resources released. That is a bad practice for resource intensive objects-- such as Graphics.

Depending on the size Bitmaps may also be resource hungry as they can eat a lot of RAM. If the bitmaps used in your code sample are never referenced after it, also ensure they're getting disposed of...