>
I hope you realize that text layout is more complex than just stackingbitmaps side by side.
Yes, I do take bearing, advance, and kerning into account when rendering the text.
> On my side, I don't quite understand why this preallocation is
> beneficial. Can you please explain the advantages?
I'm not sure what you're referring to by 'preallocation' - Are you asking about what the point is of creating a font atlas at all?
A font atlas is needed for efficient GPU-based text rendering. There has been some success in drawing glyphs on the GPU, but drawing glyphs as vectors is still a lot more expensive than a bitmap font. For real-time rendering where performance matters more than precisely-rendered text or a complete character-set, a font-atlas is a good trade.
>Perhaps we might consider some tweaks to FreeType API if it is indeed compelling.
I need a way to get the bitmap size without have to create and render a glyph. Previously, the glyph metrics worked for this, but they do not work for LCD filtered glyphs.
So my proposition would be to make the bitmap dimensions available without passing FT_LOAD_RENDER:
1) Add 3 additional fields to FT_GlyphSlotRec_
FT_Bitmap bitmap; // existing
FT_Int bitmap_left; // existing
FT_Int bitmap_top; // existing
FT_Int bitmap_width; // NEW
FT_Int bitmap_height; // NEW
FT_Int bitmap_pitch; // NEW
2) Add a new flag FT_LOAD_COMPUTE_BITMAP_DIMENSIONS to compute bitmap dimensions without having to render the glyph.
So basically, the relevant code could be factored out of ft_smooth_render_generic and used to calculate the bitmap dimensions any time a FT_GlyphSlotRec_ was created while FT_LOAD_COMPUTE_BITMAP_DIMENSIONS was provided.
Finally, I should be able to do this:
FT_Load_Char(face, code, FT_LOAD_TARGET_LCD | FT_LOAD_NO_BITMAP | FT_LOAD_COMPUTE_BITMAP_DIMENSIONS);
int w = face.glyph.bitmap_width;
int h = face.glyph.bitmap_height;
// ...
Thanks,
Nick