Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I'm developping on the LG VX6000 and the bitmaps I load take much more memory on the actual phone than on the emulator. Using IHeap, I get that the program uses 155,813 bytes right after loading images (in the app's start-up) in the emulator, while it uses 431,440 bytes on the phone.

That's almost a 300kb difference, so I'd really like to get rid of it. The rest of the program takes the same amount of memory on the emulator and the phone. Anybody else had that problem and found a solution?

Here's the code I use to load images (taken from the book "Wireless Game Development in C/C++ with BREW"):

void ImageLoader::loadImage(IShell* shell, int index, char* fileName)
{
byte * pDataBytes;
int nSize = 0;
IFile * pIFile = NULL;
IFileMgr * pIFileMgr = NULL;
boolean bVal = FALSE;
FileInfo * pFileInfo = NULL;
AEEImageInfo * pImageInfo = NULL;

//We have to malloc these instead of using stack variables because
//on a real handset we only have 500 bytes of stack!
pFileInfo = (FileInfo*)MALLOC(sizeof(FileInfo));
pImageInfo = (AEEImageInfo *)MALLOC(sizeof(AEEImageInfo));

//create the file manager object and load desired bitmap
ISHELL_CreateInstance(shell, AEECLSID_FILEMGR,(void **)&pIFileMgr);
pIFile = IFILEMGR_OpenFile(pIFileMgr, fileName, _OFM_READ);

//bad craziness
if (!pIFile)
{
assert(false);

//IFILE_Release(pIFile); // Already NULL, don't release it!
IFILEMGR_Release(pIFileMgr);
FREE(pFileInfo);
FREE(pImageInfo);

return;
}

//find out how big the file is, and load it in
IFILE_GetInfo(pIFile, pFileInfo);
nSize = pFileInfo->dwSize;
FREE(pFileInfo);

pDataBytes = (byte*)MALLOC(nSize);

IFILE_Seek(pIFile, _SEEK_START, 0);
IFILE_Read(pIFile, pDataBytes, nSize);
IFILE_Release(pIFile);

//run CONVERTBMP macro to convert our BMP to a device-dependent bitmap
_loadedImages

    .imageData = CONVERTBMP(pDataBytes, pImageInfo, &bVal);

    //See if we have allocated memory in the process
    if (bVal)
    {
    _mallocFlags

      = TRUE;
      }
      else
      {
      _mallocFlags

        = FALSE;
        }

        //clean up
        IFILEMGR_Release(pIFileMgr);
        FREE(pImageInfo);

        I found the mistake: there lacked a "FREE(pDataBytes)" in the "if(bVal)" -- on the phone, data was reallocated to hold the phone format BMP but I didn't free the Windows format data loaded before-hand. On Windows it worked fine since CONVERTBMP just returns the same pointer, but on the phone it created a big memory leak.
        There still seems to be too much data allocated however -- I'll have to investigate further to see if it is in that function.

        I found the mistake: there lacked a "FREE(pDataBytes)" in the "if(bVal)" -- on the phone, data was reallocated to hold the phone format BMP but I didn't free the Windows format data loaded before-hand. On Windows it worked fine since CONVERTBMP just returns the same pointer, but on the phone it created a big memory leak.
        There still seems to be too much data allocated however -- I'll have to investigate further to see if it is in that function.

        The emulator environment is not perfect for simulating the physical device, especially where knowing how much space the device native bitmaps are going to eat. Depending on how each device stores it's DDB, the I think the amount of space taken up after a convertbmp() can change from emulator to phone and from phone to phone too.

        The emulator environment is not perfect for simulating the physical device, especially where knowing how much space the device native bitmaps are going to eat. Depending on how each device stores it's DDB, the I think the amount of space taken up after a convertbmp() can change from emulator to phone and from phone to phone too.

        I believe the reason too much RAM is taken is because the native bitmap format is always in 16 bit. Therefore, a 8 bits windows bitmap would take about twice as much RAM once converted in 16 bits per pixel. Anybody can confirm/deny this possibility? If this is true then it's rather annoying since it pretty much cuts RAM by half on graphics-intensive software.

        I believe the reason too much RAM is taken is because the native bitmap format is always in 16 bit. Therefore, a 8 bits windows bitmap would take about twice as much RAM once converted in 16 bits per pixel. Anybody can confirm/deny this possibility? If this is true then it's rather annoying since it pretty much cuts RAM by half on graphics-intensive software.

        Yes the handset expands your bitmap to 16-bit, which takes up more space than your 8-or 4-bit bitmap.
        I would recommend using the emulator form the 2.0 SDK. It muc better reflects the behavior of the handset in that respect, as it also expands bitmaps to 16-bit if you use a 16-bit emulator skin. It also has a few other handy features than the 1.1 emulator.

        Yes the handset expands your bitmap to 16-bit, which takes up more space than your 8-or 4-bit bitmap.
        I would recommend using the emulator form the 2.0 SDK. It muc better reflects the behavior of the handset in that respect, as it also expands bitmaps to 16-bit if you use a 16-bit emulator skin. It also has a few other handy features than the 1.1 emulator.