Funny stuff - when your camera has 2GB of ram, and you have a problem to find just about 3MB for yourself.
Our current progress uses
a lot of ram considering "regular" Digic 4/5 cameras:
- ~500kb already used by Zebra for double buffering
- ~500kb for indexed RGB buffer that emulates old style of drawing (so we don't need to rewrite a lot of GUI code)
- ~500kb for bitmap font (gone from D6+ ROMs, at the moment I loaded one extracted from my 50D)
- ~2MB for RGBA layer (see
thread on Compositor)
This is already more than regular memory available on R
While 3rd and 4th are optional:
- Bitmap font was already mostly replaced, and we will either prepare a much smaller BMP font that we can distribute, or get rid of it at all
- Own compositor layer can be avoided - at the moment it has no big benefits over drawing directly to GUI layer like 200D, M
it is still less than 3MB of memory available
For the last two days with names_are_hard I was looking at memory management functions. In general there are two main allocators (malloc/free and AllocateMemory/FreeMemory) that can be "freely" used.
What I noticed is that 2nd one (AllocateMemory/FreeMemory) just wraps calls to more general functions that take memory pool address as first param. Those functions are also used by some other components. It turns out that Canon has nice "class" for managing memory area - called... you guessed it, MemoryManager.
There's just a single function to initialize - takes just start memory address and memory length. After using it over arbitrary block of memory (of course assuming it is not used by anyone else) one can just call any of those general functions (e.g.
void* ptr = AllocateMemory_impl(pMemMgr, size) or
FreeMemory_impl(pMemMgr, ptr).
As I found potentially unused 4MB memory block, I was able to just initialize MemoryManager and substitute functions stubs with ones that wrap into that block. Code is fairly clean and simple and you can
see it in this commit in my repo.
While my code just replaces usage of usual Canon pool, it can be integrated as additional space into our memory management system. I just replaced it as this way I was able to keep my changes in platform dir for now, and this way code is forced to use it - so I'll probably see some crashes is something else uses the mentioned memory area. Hopefully it won't happen
