Optimizing Pango OpenType engine

[Behdad Esfahbod <behdad cs toronto edu>]

[misspelled list name the first time, resending]

Hi Owen,

As you may have noticed, I'm working around the
pango/pango/opentype these days.  I've found a lot of places to
improve, and guess I'm going to rewrite the whole thing
eventually.  I would like to know how do you prefer me to work on
this:

  * File different bugs for different issues, attach small
patches.  This typically fails, since most of such patches would
conflict each other.

  * Attach small comulative patches to the same bug.

  * Update one big patch that obsoletes old ones and implement
all points.

  * Commit trivial fixes/enhancements.

  * Branch and work there.


On my top is to commit, of course :).  I really prefer to commit
to some CVS instead of moving around zillion patches.

Moreover, do you have any advice about this project?  Anything
you want to see implemented there?  Any hints?  I've thought of
following things so far:

  - Reduce number of memory allocations, so faster startup times.
Currently loading Arabic tables of Tahoma does 120 allocs and
reallocs, 42 of them are allocating only 2 bytes.  For loading
the whole supported tables, according to HELLO.utf8, these
numbers are 702, 231.

  - Reduce memory footprint by implementing inheritance by
subtyping instead of union-ing all subtypes.

  - Share code between gsub and gpos subsystems by carefully
designing data structures.

  - Use call tables were appropriate, to speed up switches.

  - Use dynamic bitmasks for short coverage maps, avoiding
bsearch in busy code path.

  - Move checks and whatever possible out of loops for faster
busy code path, like looking up LookupFlag (and lots of other
things) out of Do_Glyph_Lookup and in Do_String_Lookup once.

  - Maybe: Map some structures directly on the mapped font file
instead of reading them.

  - Long term: Cache OpenType structure of fonts in a file?


Regards,
--behdad
http://behdad.org/