[HarfBuzz] No kerning?

Jamie Dale jamiedale88+harfbuzz at gmail.com
Tue Oct 6 10:52:11 PDT 2015


I did some profiling (still with our caching enabled, I'll try again later
with it disabled). These are inclusive sample percentages, which actually
makes them slightly clunky - I'll try and get some instrumentation timings
too.

The total percentage of time spent in hb_shape for the first profile is
16.9% (281 samples), of that, 13.9% (231 samples) was spent in
_hb_ot_layout_create, with 10.6% (176 samples) spent in the call to
OT::Sanitizer<OT::GPOS>::sanitize. I noticed that within the call
to sanitize, 3.7% (63 samples) was spent calling DEBUG_MSG_LEVEL (from
check_range and check_array).

I stubbed out the DEBUG_MSG_* macros to see what difference that would
make. The total percentage of time spent in hb_shape for the second profile
is 11.4% (112 samples), of that, 7.7% (76 samples) was spent in
_hb_ot_layout_create, with 4.2% (41 samples) spent in the call to
OT::Sanitizer<OT::GPOS>::sanitize.

I wouldn't put too much stock into those figures, as sample based profiling
can easily be influenced by human elements when interacting with the UI,
however it does let me raise two points:

1) Why are the DEBUG_MSG_* macros not stubbed out in non-debug builds (eg,
when HB_DEBUG != 0)?
2) What is OT::Sanitizer doing, and could it be skipped without leading to
crashes?

Thanks,
Jamie.

On 5 October 2015 at 22:31, Jamie Dale <jamiedale88+harfbuzz at gmail.com>
wrote:

> hb_ft_font_set_flags sounds basically like what I'm already doing using
> user-data, so yeah, that sounds like it would be fine.
>
> I'll see if I can get you some stats (I can't remember off the top of my
> head), but I'd certainly be willing to help try out caching patches to
> hb-ft.
>
> The main reason we just went with our own caching is that it already
> existed, and we still have some font rendering that doesn't go through
> shaping (and likely never will) so this keeps our font caching unified
> between our character-based and glyph-based (shaped) font rendering paths.
> With our FreeType caching applied, I can say that the slowest part is the
> OT code (I have recollections of something along the lines of
> OT::Sanitizer showing up on my profiles), and it also seems that
> hb_shape_plan_create_cached never actually caches (or if it does, it
> doesn't do it often enough to avoid repeated work - although  I'm not sure
> if it *is* caching and then I'm just losing that cached data somehow).
>
> -Jamie.
>
> On 5 October 2015 at 22:20, Behdad Esfahbod <behdad.esfahbod at gmail.com>
> wrote:
>
>> Thanks Jamie,
>>
>> For loadflags, would it be enough to add hb_ft_font_set_flags() that sets
>> loadflags, and use that in all places?  I'll go ahead and do that, since
>> it's
>> been long overdue.
>>
>> Re caching, do you have data you can share on which parts are the slowest,
>> etc?  Would you be willing to test a couple of patches if I add caches to
>> hb-ft?
>>
>> Thanks,
>> behdad
>>
>> On 15-10-05 05:02 PM, Jamie Dale wrote:
>> > Sure, I've attached the font file we're using.
>> >
>> > Unfortunately, I don't think our caching solution is anything that
>> could be
>> > easily made HarfBuzz friendly, as it builds upon our existing font
>> caching
>> > mechanisms (our use case here is real-time games) and uses a font atlas
>> (plus
>> > a series of granular caches) to avoid repeatedly asking FreeType for
>> the same
>> > data. It is itself heavily reliant on our engine code, and makes
>> extensive use
>> > of our custom user-definable composite fonts (which allow users to
>> create
>> > their own localisable font families). Our composite fonts also allow
>> you to
>> > specify which hinting method to use for each font face (as this can
>> produce
>> > nicer results for certain fonts, such as using light hinting with thin
>> fonts),
>> > which is why we need to preserve this FreeType hinting behaviour with
>> HarfBuzz
>> > (they're just extra FreeType load flags).
>> >
>> > -Jamie.
>> >
>> > On 5 October 2015 at 21:24, Behdad Esfahbod <behdad.esfahbod at gmail.com
>> > <mailto:behdad.esfahbod at gmail.com>> wrote:
>> >
>> >     I'm not sure what's wrong.  Can you send me the font file?
>> >
>> >     Also, I'm interested to hear more about your caching and load-flags
>> stuff.  I
>> >     like to upstream them to the extent that makes sense.
>> >
>> >     behdad
>> >
>> >     On 15-10-05 03:32 PM, Jamie Dale wrote:
>> >     > Hey all,
>> >     >
>> >     > In our application we have two text shaping backends; a simple
>> "kerning only"
>> >     > implementation using our existing font rendering code (fast, but
>> can't handle
>> >     > complex languages), and a HarfBuzz based implementation for when
>> we need to
>> >     > support complex languages (although ideally the HarfBuzz
>> implementation should
>> >     > be able to produce mostly equivalent results when compared to our
>> existing
>> >     > font rendering when dealing with languages like English).
>> >     >
>> >     > If you've seen my previous email entitled "Using FreeType load
>> flags", then
>> >     > you'll know I'm using some custom font functions to try and
>> ensure HarfBuzz
>> >     > uses the correct FreeType hinting flags, as well as cache a lot
>> of FreeType
>> >     > calls, and use the correct scale.
>> >     >
>> >     > So far this has worked out really well, however I've noticed that
>> the HarfBuzz
>> >     > implementation isn't applying kerning when shaping English text
>> (probably
>> >     > other languages too).
>> >     >
>> >     > The images below are using the Roboto font, and show the output
>> from each
>> >     > implementation.
>> >     > The top image is using our "kerning only" implementation, and the
>> bottom image
>> >     > is using HarfBuzz. Note that the "T" and "e" characters are
>> further apart in
>> >     > the bottom image.
>> >     > Inline images 2
>> >     > Inline images 1
>> >     >
>> >     > Here's the (slightly cut down) code I'm using to create my
>> HarfBuzz font:
>> >     >
>> >     > hb_font_t* CreateHarfBuzzFont(FT_Face InFace, const uint32
>> InGlyphFlags,
>> >     const
>> >     > int32 InFontSize, const float InFontScale)
>> >     > {
>> >     > hb_font_t* HarfBuzzFont = nullptr;
>> >     >
>> >     > // Set the character size to render at (needs to be in 1/64 of a
>> "point")
>> >     > FT_Set_Char_Size(InFace, 0, InFontSize * 64, 96, 96);
>> >     >
>> >     > if (InFontScale != 1.0f)
>> >     > {
>> >     > FT_Matrix ScaleMatrix;
>> >     > ScaleMatrix.xy = 0;
>> >     > ScaleMatrix.xx = (FT_Fixed)(InFontScale * 65536);
>> >     > ScaleMatrix.yy = (FT_Fixed)(InFontScale * 65536);
>> >     > ScaleMatrix.yx = 0;
>> >     > FT_Set_Transform(InFace, &ScaleMatrix, nullptr);
>> >     > }
>> >     > else
>> >     > {
>> >     > FT_Set_Transform(InFace, nullptr, nullptr);
>> >     > }
>> >     >
>> >     > {
>> >     > // Create a sub-font from the default FreeType implementation so
>> we can
>> >     > override some font functions to provide low-level caching
>> >     > hb_font_t* HarfBuzzFTFont = hb_ft_font_create(InFace, nullptr);
>> >     > HarfBuzzFont = hb_font_create_sub_font(HarfBuzzFTFont);
>> >     > hb_font_destroy(HarfBuzzFTFont);
>> >     > }
>> >     >
>> >     > hb_font_set_funcs(...); // Sets functions that use the user-data
>> below,
>> >     > implementations are mostly default, but with a caching layer, and
>> usage of
>> >     > FreeType hinting flags
>> >     > hb_font_set_user_data(...); // Ensures we have access to
>> InGlyphFlags
>> >     and the
>> >     > low-level caches
>> >     > hb_font_set_scale(HarfBuzzFont, InFontScale, InFontScale);
>> >     >
>> >     > return HarfBuzzFont;
>> >     > }
>> >     >
>> >     > Am I just missing something simple? I tried calling
>> hb_font_set_ppem but
>> >     that
>> >     > didn't seem to make any difference.
>> >     >
>> >     > Thanks,
>> >     > Jamie.
>> >     >
>> >     >
>> >     > _______________________________________________
>> >     > HarfBuzz mailing list
>> >     > HarfBuzz at lists.freedesktop.org <mailto:
>> HarfBuzz at lists.freedesktop.org>
>> >     > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>> >     >
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20151006/42788088/attachment-0001.html>


More information about the HarfBuzz mailing list