Re: Optimizing Pango OpenType engine

On Tue, 2005-03-22 at 03:20 -0500, Behdad Esfahbod wrote: 
> [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. 

If you are going to be doing extensive work, you might want to
think about doing it in the context of an independent module
in freetype CVS rather than in Pango.

What I was planning to do was to take the code in Pango CVS,
import it into the otlayout/, then redo the work that David
did in otlayout/ to make it work on memory buffers rather than
FreeType streams.

I never got final sign off from David on this plan, but he's
back around now, so probably just needs to be repinged.

>  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.

This is really the best. It's OK if they don't apply cleanly
by themselves, but they should be independent for the purposes
of review.

>   * Attach small comulative patches to the same bug.

I'd rather see cumulative patches in different bugs.

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

This makes review pretty difficult.

>   * Commit trivial fixes/enhancements.

The opentype code really is pretty tricky ... my experience
is that few patches to it are right the first time. So, I'd like
to get multiple pairs of eyes looking at any changes. It doesn't
have to be me ... if you can get someone else who is familiar
with the code to review changes, that's OK with me.

>   * Branch and work there.

If you want to work in a branch in CVS, that's fine with me, but
I'd still like to see the output broken up into patches.

> 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 haven't spent a lot of time profiling the OpenType code, so I don't 
have a lot of ideas about how to make it faster. My main goals at this
point, if I had time to work on the code myself would be:

 - Stop using FreeType internal headers
 - Get to a common codebase with Qt

Bugs turn up in the code on a very regular basis, and having to
sync multiple code bases is a big problem.

>  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.

120 allocs/reallocs isn't very much.... it's not going to show
up on profiles. Perhaps loading lookups lazilly as needed would
help reduce the number. 

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

You probably could keep the unions and just allocate the memory
for the branches you are using, though that can be a little
tricky. Do you have numbers for how much memory could be 
saved here.

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

There might not be a big advantage to this ... it does feel
like there is a lot of almost exactly duplicated code, but I'm
not sure if it can be factored without considerable more

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

As far as I know, GCC already does this. Doing it manually
won't be a win.

>   - 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.

This would be pretty much a rewrite... it certainly is a more
memory efficient way of doing things. I don't have a good sense about
the relative performance benefits. If you were going to go this 
way, you almost certainly want a separate validation pass, like the
stuff Werner wrote so that you aren't constantly validating the

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

If you are going to use mmap structures, it's probably best 
to just use the tables in the fonts, as in your previous item
instead of reinventing some new format.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]