[Top][All Lists]

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

[Devel] 2.1.9 Tagged in CVS

From: David Turner
Subject: [Devel] 2.1.9 Tagged in CVS
Date: Thu, 24 Jun 2004 09:03:53 +0200
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)


I've just tagged the next release in CVS (with VER-2-1-9). The tarballs
should be ready tonight if everything goes well.

Please test wathever you can in the meantime.


- David Turner
- The FreeType Project  (

By the way, I've added a new benchmark to "ftbench", used to measure the
performance of (FT_New_Face/FT_Done_Face). This allowed me to spot a
_serious_ performance problem when the BDF/PCF drivers are listed
before the TrueType/Type1 ones in "ftmodule.h"

The reason is that these drivers do allocate very large buffers to either
perform decompression or parsing, even if this is only to test a few bytes
in the font file header to check the format. This is a bit stupid.

Moving the TrueType driver to the top of the list changed the open/close
performance of Vera.ttf on my machine from 1550 us to 330 us, i.e. a nearly
5x speedup !!

I've also used kcachegrind to visualize the bottlenecks with various
benchmarks. This allowed me to spot that:

- before changing the list of drivers, 58% of the time taken to open
  a font file was taken by "memset". This resulted from the fact that
  FT_Alloc does clear the allocated block, which isn't always necessary
  (especially for large ones, like in the PCF/BDF/GZip drivers).

  I have thus introduced new functions FT_QAlloc and FT_QRealloc
  (the Q stands for "Quick"), with corresponding macros and a few
  modifications to the sources (more will follow)

- another benchmark: the open/face performance of a pcf.gz file is
  _extremely_ poor (about 30x slower that opening a truetype font
  file). I'm thinking about rewriting the gzip module to simply
  uncompress the whole file in memory in one pass, instead of
  resetting the decompression each time we seek back in the file.
  Given that we only use this for small PCF or BDF files, it
  shouldn't be a big problem in practice (and who does use large
  bdf.gz files anyway :-)

- interesting comparisons when loading hinted glyphs from Vera.ttf
  on my machine (1.7 GHz Pentium 4-M):

     bytecode interpreter:   20 us/operation
     autohinter:             41 us/operation
     autofitter:             29 us/operation

  Clearly, the auto-fitter will become the default after the 2.1.9
  release :-)

kcachegrind is a marvelous tool by the way, try it if you can.
Too bad it requires KDE3, or we'd be using it at work everyday...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]