diff options
Diffstat (limited to 'Build/source/libs/freetype/docs/optimize.txt')
-rw-r--r-- | Build/source/libs/freetype/docs/optimize.txt | 181 |
1 files changed, 0 insertions, 181 deletions
diff --git a/Build/source/libs/freetype/docs/optimize.txt b/Build/source/libs/freetype/docs/optimize.txt deleted file mode 100644 index 2f7af918eca..00000000000 --- a/Build/source/libs/freetype/docs/optimize.txt +++ /dev/null @@ -1,181 +0,0 @@ - - FreeType Optimization HOWTO - - - -Introduction -============ - - This file describes several ways to improve the performance of the - FreeType engine on specific builds. Each `trick' has some - drawbacks, be it on code size or portability. - - The performance improvement cannot be quantified here simply - because id depends significantly on platforms _and_ compilers. - - - -I. Tweaking the configuration file -================================== - - The FreeType configuration file is named `ft_conf.h' and contains - the definition of various macros that are used to configure the - engine at build time. - - Apart from the Unix configuration file, which is generated when - calling the `configure' script from the template called - - freetype/ft_conf.h.in , - - all configuration files are located in - - freetype/lib/arch/<system>/ft_conf.h , - - where <system> stands for your platform. This release also - provides an `ansi' build, i.e., the directory `lib/arch/ansi' used - to compile with any ANSI-compliant compiler. - - The configuration macros that relate to performance are described - next. - - - 1. TT_CONFIG_OPTION_INTERPRETER_SWITCH - -------------------------------------- - - If set, this macro builds a bytecode interpreter which uses a - huge `switch' statement to parse the bytecode stream during - glyph hinting. - - If unset, the interpreter uses a big jump table to call each - bytecode's routine. - - This macro is *set* by default. However, it may be worthwile on - some platforms to unset it. - - Note that this macro is ignored until - TT_CONFIG_OPTION_BYTECODE_INTERPRETER is set. - - - 2. TT_CONFIG_OPTION_STATIC_INTERPRETER - -------------------------------------- - - If set, this macro builds a bytecode interpreter which uses a - static variable to store its state. On some processors, this - will produce code which is bigger but slightly faster. - - Note that you should NOT DEFINE this macro when building a - thread-safe version of the engine. - - This macro is *unset* by default. - - - 3. TT_CONFIG_OPTION_STATIC_RASTER - --------------------------------- - - If set, this macro builds a scan-line converter which uses a - static variable to store its state. On some processors, though - depending on the compiler used, this will produce code which is - bigger but moderately faster. - - Note that you should NOT DEFINE this macro when building a - thread-safe version of the engine. - - This macro is *unset* by default. We do not recommend using it - except for extreme cases where a performance `edge' is needed. - - - 4. TT_USE_LONG_LONG - ------------------- - - Define TT_USE_LONG_LONG if you want to enable the use of the - 'long long' 64-bit type provided by gcc and other compilers. - Note that: - - 1. The type wasn't ANSI C in 1989 (but is now OK with the new - C99), and thus will produce many warnings during library - compilation with many compilers, including gcc 2.8.x. - - 2. Though the generated object files are slightly smaller, the - resulting executables are bigger of about 4kB! gcc must be - linking some extra code in there! - - 3. There is really no speed gain in doing so (but it may help - debug the ttcalc component). - - IMPORTANT NOTE: You don't need to define it on 64-bits machines! - - NOTE 2 : This flag used to be _GNUC_LONG64_ - - - -II. Replacing some components with optimized versions -===================================================== - - You can also, in order to improve performance, replace one or more - components from the original source files. Here are our - suggestions. - - - 1. Use memory-mapped files whenever available - --------------------------------------------- - - Loading a glyph from a TrueType file needs many random seeks, - which take a lot of time when using disk-based files. - - Whenever possible, use memory-mappings to improve load - performance dramatically. For an example, see the source file - - freetype/lib/arch/unix/ttmmap.c - - which uses Unix memory-mapped files. - - - 2. Replace the computation routines in `ttcalc.c' - --------------------------------------------------- - - This file contains many computation routines that can easily be - replaced by inline-assembly, tailored for a specific processor - and/or compiler. - - After heavy testing, we have found that these functions, - especially TT_MulDiv(), are the ones that are most extensively - used and called when loading glyphs from a font file. - - We do not provide inline-assembly with this release, as we want - to emphasize the portability of our library. However, when - working on a specific project where the hardware is known to be - fixed (like on an embedded system), great performance gains - could be achieved by replacing these routines. - - (By the way, the square root function is not optimal, but it is - very seldom called. However, its accuracy is _critical_. - Replacing it with a fast but inaccurate algorithm will ruin the - rendering of glyphs at small sizes.) - - - -III. Measuring performance improvements -======================================= - - Once you have chosen some improvements and rebuilt the library, - some quick ways to measure the `new' speed are: - - - Run the test program `ftlint' on a directory containing many - TrueType fonts, and measure the time it takes. On Unix, you can - use the shell command `time' to do it like in - - % time test/ftlint 10 /ttfonts/*.ttf - - This will measure the performance improvement of the TrueType - interpreter. - - - Run the test program `fttimer' on a font containing many complex - glyphs (the latest available versions of Times or Arial should - do it), probaby using anti-aliasing, as in: - - % time test/fttimer -g /ttfonts/arial.ttf - - Compare the results of several of these runs for each build. - - ---- end of OPTIMIZE --- |