`hb_ot_layout_lookup_collect_glyphs` very slow

[lemzwerg]

Please see

https://lists.freedesktop.org/archives/harfbuzz/2016-October/005809.html

for the complete report; this is something hb-view and friends doesn't test.

[lemzwerg]

BTW, you can simply use ftview for debugging (linked to harfbuzz); it also exhibits the enormous slow-down.

[behdad]

Hi Werner. You sure this is still an issue with latest HarfBuzz? I can reproduce with very old version, but not master. Thanks.

[behdad]

This was supposed to fix this issue in 2014:

commit fde3e4a423871463c883cb969e99c29cb6f69f6b
Author: Behdad Esfahbod <behdad@behdad.org>
Date:   Wed Oct 29 11:23:08 2014 -0700

    In hb_ot_collect_glyphs(), don't recurse to a lookup more than once
    
    Otherwise, we might process a lookup thousands of times, with no
    benefit.  This pathological case was hit by Noto Nastaliq Urdu Draft
    in Firefox's code to determine whether space glyph is involved in
    any GSUB/GPOS rules.  A test page is at http://behdad.org/urdu
    
    See:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1090869

[lemzwerg]

I've probably attached a wrong example, sorry. Right now I've recompiled both harfbuzz and FreeType from git, and running `ftfuzzer' takes 8 minutes on my notebook to process this file.

[behdad]

Right. Repro'ed.

[behdad]

Ok. Fixed. The issue was that a Format2 coverage table can specify covering 64k glyphs in just four bytes, and then we were looping over those and trying to collect ligatures for them, which of course didn't exist. I fixed this by breaking out of loops when we run out of data instead of keep looping. Fixed it in many places, but I know there are a few more that will pop up later. Added a couple of TODO items as well.

[lemzwerg]

I can confirm the fix, thanks – and you are right with the `popping up' :-) Here is another one.

Please reopen.

[lemzwerg]

Excellent, thanks! All slow test cases I have for testing are now fixed.