Holding multiple bitmaps in memory

[sbail]

Hi all,
I'm doing some image processing on a bitmap I load from an mbm file. The program computes different gradients of the image and eventually combines them in one. My question is now, what is the most efficient way to handle several temporary versions of one image?

Creating 6 CFbsBitmap (EGray256) in one function would probably cause a big overhead.

For some reason, if I try using pointers to hold the temp values (to copy them into the final image after all the processing is done), the app crashes without any error message:

    TUint8 * tmp=new TUint8[imgSize];

    iBitmap->LockHeap(ETrue); // lock global heap 
    TUint8* final = (TUint8*)iBitmap->DataAddress();
    iBitmap->UnlockHeap(ETrue);

this works, and I can access "final", but trying something like

    tmp[0] = 255;

crashes it.

What is the most efficient way to store those temporary values? Is this just a standard C++ pointer problem?

Thanks for your help.

[wizard_hu_]

Enable the error messages: http://wiki.forum.nokia.com/index.ph...ded_panic_code
Note that "new TUint8[imgSize]" returns a NULL pointer when it runs out of memory - if you get a KERN-EXEC 3 panics, probably this is the case.
You can increase the size of your heap (default maximum size is 1 megabyte) using the EPOCHEAPSIZE keyword in the .mmp (.mmp editor in Carbide.c++ also offers it on one of its pages).

[sbail]

Thanks for your quick reply - on Exit() the program leaves with a KERN-EXEC 3 panic, but not during execution. When I try to use the emulators debug now function, the emulator crashes, haha.

I'll try and change the heap size, does that normally solve memory problems? (My program is only a prototype and optimised for an N95, does not need to be compatible with other phones )

[wizard_hu_]

In your first post you wrote that "tmp[0]=255" dies, and that could be a memory problem. Now decide if it dies or not.
About the emulator issue, check http://wiki.forum.nokia.com/index.ph...arbide.c%2B%2B

[sbail]

Sorry, the description of the crash was not quite clear, due to the fact that the behaviour and crashes changed with every run (and I couldn't spot a pattern...).

I've increased the heap size now and it seems stable, no more crashes. So I guess the problem is solved... learned something new today.

Thanks for your help!

[wizard_hu_]

Note that if you use the Symbian-ish

TUint8 * tmp=new (ELeave) TUint8[imgSize];

syntax, you would always get a clear notification about out of memory situations (a leave with KErrNoMemory).