I think this could work, but the allocation/deallocations should be avoided as well:
I suppose FT_GlyphSlotRec doesn't need 3 extra fields then, and the information can just be put into FT_GlyphSlotRec::bitmap. For some reason, I thought that FT_GlyphSlotRec::bitmap was allocated when the glyph was rendered, but I was mistaken. FT_GlyphSlotRec::bitmap is an instance, and not a pointer.
> Doesn't Skia do GPU-based rendering? Their current workaround is to
> preallocate old-fashioned size, which should be slightly larger or
> identical to what FreeType eventually returns, then they eventually
> adjust dimensions to the actual image,
I don't know, but I need to be able to pack a font atlas tightly to hold all the required characters, and adding 2 pixels of padding to all characters would be wasteful. There is a long and complicated list of things to keep in mind when dealing with font atlases, but long-story-short, being able to perform a layout pass over all the glyphs you want to use without having to allocate or render everything would be a big win.
See first picture for "font atlas"
> If I follow, you'd like to be able to interpolate between the bitmaps.
I'm don't understand what you mean.
> Maybe, LCD rendering and GPU are not a good match and should just be avoided.
I already have it working. The only problem is the performance cost of unnecessarily allocating and rendering the entire character set twice when I create a font atlas. I've been able to avoid this with the code I scraped, but as you've said, future updates could easily break my code, so I would prefer an officially supported option.
Thanks,
Nick