0

I have to correct a bug where Leadtools function " L_LoadBitmap() returns ERROR_NO_MEMORY " , more info about it you can find Here. The application I am working on has to be able to handle images despites the size of each image or their count. Here the function is called:

HENHMETAFILE hemf = 0;
BITMAPHANDLE bmh = {0}; 
    hemf = LoadMetaFile( (LPCTSTR)strPath, hDC ); 
    if ( !hemf )
    {
        memset( &bmh, 0, sizeof(BITMAPHANDLE) );
        L_INT nResult = 0;

        nResult = L_LoadBitmap( const_cast<LPTSTR>( (LPCTSTR)strPath ), &bmh, 0, ORDER_BGR );

        if ( nResult != SUCCESS )
        {
            MFDebugString( DL_FORMULAR, __FUNCTION__ "( %s ): Can't load background file via L_LoadBitmap (%d)\n", (LPCTSTR)strPath, nResult );
            return nullptr;
        }
    }
pOrigBg = std::make_shared<CBackgroundImage>(strPath, hemf, bmh);
m_ImageCache[strKey.GetString()] = pOrigBg;
return pOrigBg;

Here pOrigBgis an std::shared_ptr<CBackgroundImage> object that gets constructed this way:

NxFE::CBackgroundImage::CBackgroundImage(LPCTSTR strPath, HENHMETAFILE emf, const BITMAPHANDLE& bmp)
    : m_Filename(strPath), m_Metafile(emf), m_pLeadBitmap(new BITMAPHANDLE(bmp)),
    m_pGdiplusBitmap(NxClass::Win32::GDIPlus::CreateBitmapFromFile((LPCSTR) m_Filename))
{
}

How can you see, pOrigBg contains a std::unique_ptr of type BITMAPHANDLE and Gdiplus::Bitmap. Firstly, I thought that removing constructor of m_pGdiplusBitmap may help , but it doesn't. Is any possible way to deallocate/reduce the usage of graphic memory ? Or at least some tools of inspecting Graphic Memory Usage (I'm using Microsoft Visual Studio 2017).

  • *The application I am working on has to be able to handle images despites the size of each image or their count.* -- Is your application 64-bit or 32-bit? If it's 32-bit, you are working at a disadvantage. – PaulMcKenzie Nov 04 '19 at 13:46
  • @PaulMcKenzie it's 32-bit.. – Alexandru Pirlog Nov 04 '19 at 14:23
  • Then you are limited to 2GB of memory. You should consider going to 64-bit if you have to handle images this large in memory. – PaulMcKenzie Nov 04 '19 at 14:31
  • @PaulMcKenzie I tried to use this tool in a new 32-bit envirorment windows application , it worked properly with the same images I used for testing the main app . But clients use only 32-bit envirorment , and large size images. That's why I'm asking if is there any way to free the memory for this situation. I also tried L_ReleaseBitmap() and L_FreeBitmap() but Images still fail to load on a certain count. – Alexandru Pirlog Nov 05 '19 at 07:00

2 Answers2

1

As you found out, functions in LEADTOOLS that allocate pixel data must be followed by calling L_FreeBitmap() when you no longer need the bitmap in memory. This is actually mentioned in the help topic you mentioned in your original question, which states: “Since the function allocates storage to hold the image, it is up to you to free this storage by calling L_FreeBitmap.”

Placement of the L_FreeBitmap call can be crucial in avoiding memory leaks. Since pixel data is typically the largest memory object in the bitmap handle, failing to free it correctly could cause huge leaks.

Also, if your code is allocating the BITMAPHANDLE structure itself using the “new” operator, you need to delete it once done with it. Even though the structure itself is typically much smaller in size than the pixel data, you should never allow any type of memory leak in your application.

If you run into any problem related to LEADTOOLS functions, feel free to email the details to our support address support@leadtools.com. Email support is free for all versions of the toolkit, whether Release (purchased) or free evaluation.

LEADTOOLS Support
  • 2,755
  • 1
  • 12
  • 12
0

Ok, this statement worked, just had to put it in a different place

if ((bmh).Flags.Allocated)
                L_FreeBitmap(&bmh);

Still got problems with GdiplusBitmap and loading images with .bmp extension, but that's already something else. Also, in VS2017 you can go Debug -> Performance Profiler()... (Alt+F2) to use some tools for inspecting CPU / GPU / Memory Usage.