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. http://lists.gnu.org/archive/html/freetype-devel/2004-08/msg00036.html 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 complexity. > - 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 tables. > - 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part