[ft-devel] Proposal: add a raster specific allocation function to the memory management API

[Chris Liddell]

Hi,

I guess this is primarily aimed at Werner, but posted here for any
interested parties to comment.


I'd like to add a callback to the memory management specifically for
(re)allocating bitmap/raster memory.

My intention would be to have the API call take a bitmap struct as it's
parameter, and the allocated address would be added to the structure by
the function, with a return code to indicate success/failure. This would
allow Freetype consumers to have Freetype render directly into their own
buffers, with raster alignment suited to their own needs.

Using my own special interest as an example (use of Freetype in
Ghostscript), at the moment glyphs are rendered to a Freetype bitmap,
and are then copied, either into GS's own glyph cache bitmap, or to
other GS internal bitmaps depending on their end use. This is done for
two reasons, 1) because (partly due to the original integration)
Freetype is left largely in charge of the bitmap lifespan, and 2)
because Ghostscript uses and expects a different raster alignment.

By allowing the calling application, in this case Ghostscript, to know
it is allocating bitmap memory, and by allowing it to modify (well,
increase) the raster line alignment, we (and hopefully others) could
avoid copying entire bitmaps from Freetype bitmap memory to the
application's own buffer - in our case, enable us to insert the bitmap
directly in the glyph cache, or wherever it needed to go.

I did a little investigating, and a little experimenting, and the
Freetype rendering code (as of 2.4.1) seems fairly agnostic about the
raster alignment used, so hopefully the code changes required would be
relatively small - this is made easier since, I think, Freetype
currently uses what is probably the smallest reasonable alignment, so
any consumer will likely only ever want to increase it.

Mainly, I wanted to check whether this type of capability would be seen
as beneficial enough to warrant including, before I spend too much more
time on it! Especially as it is a change in the "public" API.

Thoughts, opinions, flames?

Chris