I need to create a CFbsBitmap from Raw RGB data available with me.
I am doing something like this.
iBitmap = new(ELeave) CFbsBitmap; iBitmap->Create(dispSize, EColor64K);//dispSize is a TSize of my bitmap
iBitmap->LockHeap(); Mem::Copy(const_cast<TUint32*>(iBitmap->DataAddress()), data ,X *Y* bitsPerPixel); iBitmap->UnlockHeap();
then I am drawing it following way
iFbsBitGc->BitBlt(iBitmapLocPoint, iBitmap);
it works perfectly fine, but i have few doubts
When i call Create() bitmap is created on the heap that belongs to the bitmap server. so when i call DataAddress() i get a TUint32* pointer address that should be local to my current process(i.e. virtual address from my process's memory). So when I call Mem::Copy() it takes 2 ddresses one src and one dest, both local to my process(again virtual addresses from my process memory). So that means that data gets copied to some location within my process's heap. So how is it copied to the heap of bitmap server.
The font and bitmaps heap is created as a "global heap".
This means it will get mapped into your process' virtual memory space too.
So the address returned by DataAddress() is not into your process heap, its directly into the global heap of the FBS.
The technique is commonly known as "shared memory" in multi-thread/process programming.
Thats the reason you have to call "LockHeap" and "unlockheap" before using it, since the heap is under the control of another thread, you must lock it so the other thread (the FBS) wont try to change its layout while you are using it.
Foot note: In S60 3rd edition and above, you actually don't strictly need to call LockHeap/UnlockHeap (they have rewritten the heap implementation so it never needs to be compressed and the calls are just no-ops), but you still should do it to be sure to be future source compatible...
Forum posts: 1419
The font and bitmaps heap is created as a "global heap".
This means it will get mapped into your process' virtual memory space too.
So the address returned by DataAddress() is not into your process heap, its directly into the global heap of the FBS.
The technique is commonly known as "shared memory" in multi-thread/process programming.
Thats the reason you have to call "LockHeap" and "unlockheap" before using it, since the heap is under the control of another thread, you must lock it so the other thread (the FBS) wont try to change its layout while you are using it.
Foot note: In S60 3rd edition and above, you actually don't strictly need to call LockHeap/UnlockHeap (they have rewritten the heap implementation so it never needs to be compressed and the calls are just no-ops), but you still should do it to be sure to be future source compatible...
Forum posts: 3
CFbsBitmap::Save will save to a native MBM too if you feel like writing the code to use a CImageDecoder to load the source image first.