The hb_font_t object holds on to tables of font data, acquired through
the MinikinFont::GetTable interface, which is based on copying data
into caller-owned buffers. Now that we're caching lots of hb_font_t's,
the cost of these buffers is significant.
This patch moves to a different interface, inspired by HarfBuzz's
hb_reference_table API, where the font can provide a pointer to the
actual font data (which will often be mmap'ed, so it doesn't even
consume physical RAM).
Bug: 27860101
Change-Id: Id766ab16a8d342bf7322a90e076e801271d527d4
This patch eagerly purges the corresponding hb_font_t object from
the HbFontCache when the underlying MinikinFont is destroyed. After
that, the key will no longer be accessed, so having the entry is
wastes memory.
Bug: 27251075
Bug: 27860101
Change-Id: I1b98016133fe3baf6525ac37d970a65ddccadb4f
It turned out that hb_font_t creation is not a lightweight operation.
Especially, Paint.hasGlyph creates hb_font_t for all existing fonts
every time. To improve the performance, cache hb_font_t instead
of hb_face_t.
Note that to calculate horizontal advance, MinikinPaint needs to be
associated with hb_font_t by calling hb_font_set_funcs. With this patch,
hb_font_set_funcs may be called multiple times for the same hb_font_t
object. However this is not an issue since MinikinPaint is unique
during layout.
Bug: 26784699
Change-Id: I516498ae9f0127d700fc9829327e9789845a1416
