FT_Load_Glyph speedup

[molind]

Hello,

We use harfbuzz inside of mobile application Galileo along with SDF renderer. Extremely satisfied by result.

Recently I've looked in profiler to find new bottlenecks and noticed that FT_Load_Glyph causes huge performance slow down on devices with slow internal memory (e.g. iPhone 6). It' takes up to 2 seconds to compute extents and load glyphs information. Mostly because FT_Load_Glyph is slow and calls to FT_Load_Glyph is not cached.

I suggest to use FreeType cache system instead of reading the same data over and over again. What do you think?

harfbuzz/src/hb-ft.cc

Lines 250 to 275 in 20e69c9

	static hb_bool_t
	hb_ft_get_glyph_v_origin (hb_font_t *font HB_UNUSED,
	void *font_data,
	hb_codepoint_t glyph,
	hb_position_t *x,
	hb_position_t *y,
	void *user_data HB_UNUSED)
	{
	const hb_ft_font_t *ft_font = (const hb_ft_font_t *) font_data;
	FT_Face ft_face = ft_font->ft_face;
	if (unlikely (FT_Load_Glyph (ft_face, glyph, ft_font->load_flags)))
	return false;
	/* Note: FreeType's vertical metrics grows downward while other FreeType coordinates
	* have a Y growing upward. Hence the extra negation. */
	*x = ft_face->glyph->metrics.horiBearingX - ft_face->glyph->metrics.vertBearingX;
	*y = ft_face->glyph->metrics.horiBearingY - (-ft_face->glyph->metrics.vertBearingY);
	if (font->x_scale < 0)
	*x = -*x;
	if (font->y_scale < 0)
	*y = -*y;
	return true;
	}

harfbuzz/src/hb-ft.cc

Lines 294 to 322 in 20e69c9

	static hb_bool_t
	hb_ft_get_glyph_extents (hb_font_t *font HB_UNUSED,
	void *font_data,
	hb_codepoint_t glyph,
	hb_glyph_extents_t *extents,
	void *user_data HB_UNUSED)
	{
	const hb_ft_font_t *ft_font = (const hb_ft_font_t *) font_data;
	FT_Face ft_face = ft_font->ft_face;
	if (unlikely (FT_Load_Glyph (ft_face, glyph, ft_font->load_flags)))
	return false;
	extents->x_bearing = ft_face->glyph->metrics.horiBearingX;
	extents->y_bearing = ft_face->glyph->metrics.horiBearingY;
	extents->width = ft_face->glyph->metrics.width;
	extents->height = -ft_face->glyph->metrics.height;
	if (font->x_scale < 0)
	{
	extents->x_bearing = -extents->x_bearing;
	extents->width = -extents->width;
	}
	if (font->y_scale < 0)
	{
	extents->y_bearing = -extents->y_bearing;
	extents->height = -extents->height;
	}
	return true;
	}

harfbuzz/src/hb-ft.cc

Lines 324 to 349 in 20e69c9

	static hb_bool_t
	hb_ft_get_glyph_contour_point (hb_font_t *font HB_UNUSED,
	void *font_data,
	hb_codepoint_t glyph,
	unsigned int point_index,
	hb_position_t *x,
	hb_position_t *y,
	void *user_data HB_UNUSED)
	{
	const hb_ft_font_t *ft_font = (const hb_ft_font_t *) font_data;
	FT_Face ft_face = ft_font->ft_face;
	if (unlikely (FT_Load_Glyph (ft_face, glyph, ft_font->load_flags)))
	return false;
	if (unlikely (ft_face->glyph->format != FT_GLYPH_FORMAT_OUTLINE))
	return false;
	if (unlikely (point_index >= (unsigned int) ft_face->glyph->outline.n_points))
	return false;
	*x = ft_face->glyph->outline.points[point_index].x;
	*y = ft_face->glyph->outline.points[point_index].y;
	return true;
	}

[khaledhosny]

Most HarfBuzz clients do some sort of caching so I think you should consider doing the same. Last I tried, just caching hb_font_ts resulted in a measurable performance boost.

[molind]

@khaledhosny Yes, we do cache hb_font_ts. Issue happened when we process some significant amount of text to render e.g. 500 - 5000 words for example. At that moment we have to get glyph extents and other information to draw glyphs correctly.

[khaledhosny]

HarfBuzz shouldn’t normally need glyph extents, are you calling hb_font_get_glyph_extents() yourself? If so, may be you should cache these.

Anyway, I don’t think we can use Freetype cache API as we don’t create the FT_Face ourselves but get it from the client.

[destman]

I will try to explain performance problem that we face with more details:
We have 95 fonts that contain all glyphs we need. All this fonts occupy 24MB so instead of loading them into memory we load them from files. In this case FreeType use memory mapping. With new devices all is fine.

But device with not very fast flash drive have problems with performance.
At our reference test ~4s was spend for text processing. In profiler we find out that our calls of hb_font_get_glyph_extents spend ~2s and shaping spend ~1.9s.

So we add cache for hb_font_get_glyph_extents (simply std::map<hb_codepoint_t, hb_glyph_extents_t>). This drops time to 18ms. Good result!

But hb_ft_get_glyph_h_advance still does not cache result of FT_Load_Glyph.
So we can improve performance even more and question is how to do this better...
Ofc we can set our own function that will return cached horizontal advance (from same cache that we add for hb_font_get_glyph_extents). But maybe it better to do caching at level of harfbuzz (either with std::map or using FreeType caching)...

harfbuzz/src/hb-ft.cc

Lines 213 to 228 in 20e69c9

	hb_ft_get_glyph_h_advance (hb_font_t *font HB_UNUSED,
	void *font_data,
	hb_codepoint_t glyph,
	void *user_data HB_UNUSED)
	{
	const hb_ft_font_t *ft_font = (const hb_ft_font_t *) font_data;
	FT_Fixed v;
	if (unlikely (FT_Get_Advance (ft_font->ft_face, glyph, ft_font->load_flags, &v)))
	return 0;
	if (font->x_scale < 0)
	v = -v;
	return (v + (1<<9)) >> 10;
	}

[behdad]

Right. This happens if hinting is enabled, as the FT_Get_Advance has to load glyph and apply hints.

I can resurrect hb_cache_t and plug it into the advance call. I had the code and intention to do that but no one ever complained about performance of this code so I removed hb_cache_t. Will give it a try.

[behdad]

I'll wait for a Pull Request, or I'll get to this eventually.

[behdad]

Closing in preference to the Pull Request.