Providing lengthier explanation for how the destroy function works on the hb_font_t but that destroying the FT_Face (and not destroying it too early) remains the client's responsibility.
Fixes this -fno-sanitize-recover=undefined check,
hb-ft.cc:869:27: runtime error: left shift of negative value -16384
#0 0x7ff8f47da843 in hb_ft_font_set_funcs /home/ebrahim/Desktop/harfbuzz/src/hb-ft.cc:869:27
#1 0x55f20a66c7d6 in font_options_t::get_font() const /home/ebrahim/Desktop/harfbuzz/util/options.cc:731:3
#2 0x55f20a668c1f in shape_consumer_t<output_buffer_t>::init(hb_buffer_t*, font_options_t const*) /home/ebrahim/Desktop/harfbuzz/util/./shape-consumer.hh:47:42
#3 0x55f20a668441 in main_font_text_t<shape_consumer_t<output_buffer_t>, 2147483647, 0>::main(int, char**) /home/ebrahim/Desktop/harfbuzz/util/./main-font-text.hh:75:14
#4 0x55f20a667f91 in main /home/ebrahim/Desktop/harfbuzz/util/hb-shape.cc:180:21
#5 0x7ff8f3df7ee2 in __libc_start_main (/usr/lib/libc.so.6+0x26ee2)
#6 0x55f20a6427ad in _start (/home/ebrahim/Desktop/harfbuzz/util/.libs/lt-hb-shape+0xd7ad)
This makes it possible to include all .cc files into build, even if not
building CoreText, Uniscribe, etc.
This was mostly to help custom builders. But also means that we can
include all files in our own build system. Not sure if we should.
Definitely simplifies things, but slightly only.
If compiler doesn't inline StructAtOffset, this was an error since we
only disable cast-align at call-site. So, move the cast out.
../src/hb-machinery.hh: In instantiation of 'const Type& StructAtOffset(const void*, unsigned int) [with Type = unsigned int]':
../src/hb-font.cc:146:85: required from here
../src/hb-machinery.hh:63:12: error: cast from 'const char*' to 'const unsigned int*' increases required alignment of target type [-Werror=cast-align]
{ return * reinterpret_cast<const Type*> ((const char *) P + offset); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/hb-machinery.hh: In instantiation of 'Type& StructAtOffset(void*, unsigned int) [with Type = unsigned int]':
../src/hb-font.cc:147:79: required from here
../src/hb-machinery.hh:66:12: error: cast from 'char*' to 'unsigned int*' increases required alignment of target type [-Werror=cast-align]
{ return * reinterpret_cast<Type*> ((char *) P + offset); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Use non-GRID-fitted values for metrics
See freetype/src/base/ftobjs.c:ft_recompute_scaled_metrics() and
the usage of GRID_FIT_METRICS inside.
Fixes https://github.com/behdad/harfbuzz/issues/1262
* Update hb-ft.cc
Makes our FT-backed hb_font_t safe to use from multiple threads. Still,
the underlying FT_Face should NOT be used from other threads by client
or other libraries.
Maybe I add a lock()/unlock() public API ala PangoFT2 and cairo-ft.
Maybe not.
Some more measurable speedup. The recent commits' speedups are as follows:
Testing with Roboto, ****when disabling kern and liga****:
Before:
FT --features=-kern,-liga
user↦ 0m0.521s
OT --features=-liga,-kern
user↦ 0m0.568s
After:
FT --features=-liga,-kern
user↦ 0m0.428s
OT --features=-liga,-kern
user↦ 0m0.470s
So, 17% speedup.
Note that FT callbacks are faster than OT these days since we added an advance
cache to FT. I don't think the difference is enough to justify adding a cache
to OT.
When not disabling kern, the thing is three times slower, so the speedups
are three times less impressive... Still, 5% not bad for a codebase that I
otherwise thought is optimized out.
Note that, because of this and other optimiztions in our main shaper,
disabling kern and liga, the OT shaper is now *faster* than the fallback
shaper. So, that's my recommendation to clients that need the absolute
fastest...