Now that we have get_h_advances() and get_nominal_glyphs() implemented, the
overhead of doing a proper atomic load would be once per run, NOT once per
glyph. So, no need to pre-load the tables to avoid that overhead.
As such, hb_ot_font_set_funcs() has become really cheap. Can *finally* make
it be default font functions on all newly created fonts!
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...
Unused as of now. To be wired up to normalizer, which would remove
overhead and allow hb-ot-font initialization to become a no-op, so
we can enable it by default.
Instead of passing a CFLAG/CXXFLAG to define HB_EXTERN, define it
directly in src/hb.hh as __declspec(dllexport) extern when we are
building HarfBuzz as DLLs on Visual Studio. Define HB_INTERNAL
as nothing without defining HB_NO_VISIBILITY when building HarfBuzz as
DLLs to avoid linker errors on Visual Studio builds.
Also "install" harfbuzz-subset.dll into $(PREFIX)\bin as the
hb-subset utility will depend on that DLL at runtime, when HarfBuzz is
built as DLLs. Since it consists of private APIs that are subject to
change, we do not install its headers nor .lib file.
"The values in the right class table are stored pre-multiplied by the
number of bytes in a single kerning value, and the values in the left
class table are stored pre-multiplied by the number of bytes in one
row. This eliminates needing to multiply the row and column values
together to determine the location of the kerning value. The array can
be indexed by doing the right- and left-hand class mappings, adding the
class values to the address of the array, and fetching the kerning
value to which the new address points."
a01194aaf4 (commitcomment-30772041)
"The tag space of tags consisting of four uppercase letters (A-Z) with no punctuation,
spaces, or numbers, is reserved as a vendor space. Font vendors may use such tags to
identify private features."
Fixes https://github.com/harfbuzz/harfbuzz/issues/1019
New numbers:
BENGALI: 353725 out of 354188 tests passed. 463 failed (0.130722%)
DEVANAGARI: 707261 out of 707394 tests passed. 133 failed (0.0188014%)
GUJARATI: 366353 out of 366457 tests passed. 104 failed (0.0283799%)
GURMUKHI: 60729 out of 60747 tests passed. 18 failed (0.0296311%)
KANNADA: 951300 out of 951913 tests passed. 613 failed (0.0643966%)
MALAYALAM: 1048136 out of 1048334 tests passed. 198 failed (0.0188871%)
ORIYA: 42327 out of 42329 tests passed. 2 failed (0.00472489%)
SINHALA: 271596 out of 271847 tests passed. 251 failed (0.0923313%)
TAMIL: 1091754 out of 1091754 tests passed. 0 failed (0%)
TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
Devanagari regressed because Uniscribe doesn't enforce the full set.
Tests added with the *-vowel-letters.txt files in tree and Noto fonts.
Based on experimenting with Uniscribe to extract grammar and categories.
Failures down from 44 to 35:
KHMER: 299089 out of 299124 tests passed. 35 failed (0.0117008%)
We still don't enforce the one-matra rule pre-decomposition, but enforce
an order and one-matra-per-position post-decomposition.
https://github.com/harfbuzz/harfbuzz/issues/667
These are only relevant to Sinhala, because they decompose in other
cases. The USE spec categorizes them all as VPst. No idea why we
weren't following that before.
Alternative woul have been to resurrect F_COMBINE that I removed in
70136a78cb
But this does it for now. I'm not sure why check-static-inits.sh didn't
catch this before. Clang -Weverything bot did:
CXX libharfbuzz_la-hb-ot-shape-complex-indic.lo
hb-ot-shape-complex-indic.cc:99:1: warning: declaration requires a global constructor [-Wglobal-constructors]
indic_features[] =
^
1 warning generated.
CXX libharfbuzz_la-hb-ot-shape-complex-khmer.lo
hb-ot-shape-complex-khmer.cc:36:1: warning: declaration requires a global constructor [-Wglobal-constructors]
khmer_features[] =
^
1 warning generated.
uint32_t was getting promoted to signed int, which is not what we wanted...
Wow, clang has become good at generating warnings...
../../src/hb-common.h:349:29: warning: signed shift result (0xFF000000) sets the sign bit of the shift expression's type ('int') and becomes negative [-Wshift-sign-overflow]
_HB_SCRIPT_MAX_VALUE = HB_TAG_MAX, /*< skip >*/
^~~~~~~~~~
../../src/hb-common.h:93:20: note: expanded from macro 'HB_TAG_MAX'
define HB_TAG_MAX HB_TAG(0xff,0xff,0xff,0xff)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../../src/hb-common.h:89:57: note: expanded from macro 'HB_TAG'
define HB_TAG(c1,c2,c3,c4) ((hb_tag_t)((((uint8_t)(c1))<<24)|(((uint8_t)(c2))<<16)|(((uint8_t)(c3))<<8)|((uint8_t)(c4))))
~~~~~~~~~~~~~~~^ ~~
../../src/hb-common.h:349:3: warning: ISO C restricts enumerator values to range of 'int' (4294967295 is too large) [-Wpedantic]
_HB_SCRIPT_MAX_VALUE = HB_TAG_MAX, /*< skip >*/
^ ~~~~~~~~~~
text-rendering-tests test MORX-32 shows that for Insertion, an unset mark is treated
as mark set at 0. This is unlike the Reordering lookup where un unset mark performs
nothing.
Fixes MORX-32.
Behdad Esfahbod
Chun-wei Fan
Sascha Brawer
Ebrahim Byagowi
mhosken
HinTak
Khaled Hosny
Volker Krause