[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) |
Hello,
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.
Regards,
- David Turner
- The FreeType Project (www.freetype.org)
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...
- [Devel] 2.1.9 Tagged in CVS,
David Turner <=