../src/OT/Var/VARC/../../../hb-decycler.hh:108:25: warning: storing the address of local variable ‘node’ in ‘*&c_15(D)->layers_decycler.hb_decycler_t::tortoise’ [-Wdangling-pointer=]
This is an algorithm I came up with, based on the Floyd's
Tortoise-Hare constant-memory linear-time linked-list cycle-detection
algorithm.
https://en.wikipedia.org/wiki/Cycle_detection#Floyd's_tortoise_and_hare
It is linear-time and malloc-free. It *eventually* detects cycles,
not immediately.
The main different with Floyd's algorithm is that this algorithm
detects cycles when one is traversing down a graph, not just a
linked list.
Our existing cycle-detection algorithms use a set-of-integers,
either hb_set_t, or more efficient in this case, hb_map_t. Those
include at least one malloc, and as such show up on profiles.
Port hb-ot-font COLRv1 to use the decycler instead of previous
hb_map_t usage for cycle detection.
benchmark-font paint_glyph on NotoColorEmoji-Regular.ttf:
Before: 8ms; After: 5.5ms. No cycle detection: 5.5ms.
FT COLRv1 API is so slow (174ms) it's not worth porting to this.
Other graphs (VARC, etc) to be ported.
Test and documentation to be added.
Simplify the API by returning only feature tags. The users of this API
would be interested only in feature enabled by default and whether the
feature is globally or partially enabled wouldn’t be of much interest in
that case. For user features, the user of the API already have full
access to them.
This should get the features on a shape plan after executing it.
Initially I wanted to return an array of tags, but then there can be
user features that are not enabled globally, so I thought returning
hb_feature_t with value and range would be better. There is a TODO since
I couldn’t figure out how to get the value and range from the feature
mask. But also it may be overkill and a simple boolean indicating wither
it is a global feature or not would be enough.
I wounder also what should happen to non-user features that are applied
selectively, like init or medi, does ot make sense to indicate whether
they are global or not?
This is inspired by the discussion in:
https://github.com/fontforge/fontforge/pull/5522#pullrequestreview-2574321449,
but it might be useful to other HarfBuzz users.
Remove the note that fonts created with hb_coretext_font_create() have
these font functions configured for them, which is not true.
hb_coretext_font_create() documents this correctly.
It is failing on Linux CI after upgrading to Ubuntu 24.04, and macOS
upload to codecov was also silently failing for a while now. We don’t do
much with the coverage data anyway.
