History log of /frameworks/minikin/libs/minikin/HbFontCache.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6c60831cfce24b0749f50f37231e0a56d8fd4b85 11-Apr-2016 Seigo Nonaka <nona@google.com> Fix minikin_unittests

This CL fixes following test cases in minikin_tests
- FontFamilyTest.hasVariationSelectorTest
- HbFontCacheTest.getHbFontLockedTest
- HbFontCacheTest.purgeCacheTest

For the fix of FontFamilyTest.hasVariationSelectorTest, removing virtual
from GetUniqueId() in MinikinFont. After [1], MinikinFont's destructor
started calling purgeHbCache() which calls virtual method,
MinikinFont::GetUniqueId(). Fortunately, the SkTypeface::uniqueID()
returns just internal value, so we can store it at the construction time
and use it instead of calling SkTypeface::uniqueID() every time.

This patch also changes purgeHbFont to purgeHbFontLocked, as all uses of
it were already under global mutex. This change avoids deadlock on
explicit unref, as when invoked by a Java finalizer from the Java object
that holds a reference to the font.

Some of the tests needed to change to using the ref counting protocol
rather than explicitly destructing font objects, as well.

[1] 9afcc6e2bd4d89e4e1deb6e18c3c4daca4e114fd

Bug: 28105730
Bug: 28105688
Change-Id: Ie5983c4869147dacabdca81af1605066cd680b3f
/frameworks/minikin/libs/minikin/HbFontCache.cpp
aaa4e3470270496e6eb80704eadecb2cb7c56bf0 07-Apr-2016 Raph Levien <raph@google.com> Avoid copying of font table data

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
/frameworks/minikin/libs/minikin/HbFontCache.cpp
9afcc6e2bd4d89e4e1deb6e18c3c4daca4e114fd 07-Apr-2016 Raph Levien <raph@google.com> Purge hb font on Minikin font destruction

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
/frameworks/minikin/libs/minikin/HbFontCache.cpp
89e80237bc27af084c9ff316d4f47abf426eced8 03-Feb-2016 Seigo Nonaka <nona@google.com> Improve Paint.hasGlyph performance by caching hb_font_t

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
/frameworks/minikin/libs/minikin/HbFontCache.cpp