Hunting memory leaks

I’ve been working recently on hunting memory on OWB.
During my tests I realized that I was able to make memory consumption increase to hundreds of mega just by scrolling !!! So the obvious solution was to run valgrind to understand where the leaks occur.
The first huge trivial leak was about Font::drawGlyphs() method. In the previous OWB release text was drawn in a BCNativeImage and it was up to BCNativeImage to free its data but it’s no longer the way it works in OWB v3. So I just had to add a delete glyphRGBABuffer to remove hundreds of mega of leaks. The fix can be found here.
Nonetheless even after this trivial fix, there was still many megas of leaks due to fonts. I have immediatly seen that it was due to a recent improvement from me in font drawing algorithm (still in Font::drawGlyphs() method). I simply forgot to release FT_Glyph data which means for a page with a lot of text, tons of leak. This fix was a bit more tricky because if I simply did a FT_Done_Glyph on the structure, I immediatly got a segfault. That was because I incremented a pointer inside FT_Glyph structure… So I simply created a temporary variable to store the address and to be able to modify it. Of course I was so proud of my fix that I forgot to fully test my fix and after a while I was smashed with a huge regression due to my fix. So I have to correct my previous fix with this one.
Finally I have also fixed some other trivial leaks to have a nicer valgrind report. Below a leak summary (a SDL version with all options):
==17568== LEAK SUMMARY:
==17568== definitely lost: 1,576 bytes in 14 blocks.
==17568== indirectly lost: 8,571 bytes in 218 blocks.
==17568== possibly lost: 0 bytes in 0 blocks.
==17568== still reachable: 1,579,458 bytes in 9,921 blocks.
==17568== suppressed: 0 bytes in 0 blocks.
Of course there is still a lot to do to fix all leaks but I think that’s a good beginning.

Olivier