[HarfBuzz] On optimizing HarfBuzz

[Just Fill Bugs]

于 06/10/2012 08:43 AM, Behdad Esfahbod 写道:

>
> What *is* a big problem is the actual OpenType lookups themselves.  And how
> bad that is depends directly on the font.  There are fonts with zero OpenType
> lookups (eg. Droid Sans), and there are fonts that have over a 100 sublookups
> for a simple shape plan (eg. Arabic Typesetting).  Seems like, currently we
> are being very inefficient for those larger fonts.  But even for simpler fonts
> with around 20 sublookups (eg. DejaVu Sans) we are doing an awful job.  I
> tried to understand this, and here are my findings.  I think I have a good
> grasp on what's causing the slowness.  Less so on how to address it, but I
> have ideas.  Note that Uniscribe doesn't seem to be nearly as affected by the
> number of lookups, so there ought to be ways to address this.
>
> To understand, lets see what the main apply() loops for GSUB and GPOS
> currently look like:
>
> 1  for each lookup {
> 2    for each glyph in buffer {
> 3      for each sublookup of the lookup {
> 4        switch on the lookup_type {
> 5          switch on the sublookup_type {
> 6            if glyph in coverage of the sublookup {
> 7              do lots of work...
>               }
>             }
>           }
>         }
>       }
>     }
>

You can construct a map between
  'lookup->sublookup->lookup_type->sublookup_type' -> 'sublookup 
coverage', before you doing the lookup.

Then simply do a

for each coverage in map:
     if glyph in coverage:
          unpack lookup, sublookup, lookup_type, sublookup_type info
          do stuff

This will only go through the
for each lookup:
     for each sublookup of the lookup:
         switch  on the lookup_type:
             switch on the sublookup_type:
loop once.

Of course you can also cache the glyph -> 
'lookup->sublookup->lookup_type->sublookup_type' info.