home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
517a.lha
/
VFont_v2.0
/
docs
/
TechnicalNotes.pp
/
TechnicalNotes
Wrap
Text File
|
1991-06-09
|
9KB
|
200 lines
TECHNICAL NOTES ABOUT THE VFONT LIBRARY
Copyright 1991 by Michael Jansson. All Rights Reserved.
This file is a part of the vfont distribution. It may only be
distributed in companion with the other parts of the vfont
distribution. It may be freely distributed for non-profitable
purposes only.
Introduction
============
This file contains technical information about the design and the
functionality of the vfont libraries. It will not give any detailed
information, but a more abstract overview of the libraries. It is a
good idea to read this text if you are planning to use the library as
an application programmer, or if you are interested in knowing how the
vfont library works.
The next step of an application programmer ought to be to look at the
included examples, and then finally use the autodocs when he/she
actually gets around to do some implementation work with the libraries.
Document History
================
This is the first version of this document, dated Tue Apr 30 01:05:11
1991. I might have missed some important aspects about the vfont
libraries, or possibly described some aspects of the library too
superficially. Get in touch with me if you are experiences such flaws
so that I can improve the readability of the document.
Creating a Font
===============
(Font Contents file) (A specific font format file)
^ ^ |
| | |
| | |
| | \|/
| +------------------------->X<==[XDF library]
| /|\
| |
| V
+-------->(TextVAttr)<-->(Font Class)
|
|
V
(Font Instance)
[Figure 1: The relation between vfont data structures.]
Creating a font involves several steps. These steps are takes when
either the OpenVFont or the OpenBFont function is called. These
functions takes a parameter that describes the characteristics of the
desired font, such as size and name. Such description can either be a
"struct TextAttr" or a "struct TextVAttr" which is an extension of the
first structure. This is a perfect analogy to the graphics library
function OpenFont and the diskfont function OpenDiskFont, which takes a
TextAttr structure as a parameter.
The library will scan through resident font classes, i.e. font
templates that has previously been loaded from disk, to see if there is
one that fits the description. It will attempt to load a font class
from a file on disk if there is no one that matches the given
description. The font class is then used to create a font instance, by
"mapping" it. A font class may be used to create several new font
instances, and a font instance may be used by several programs. A font
instance is usually just called "font" for short, and a font class is
usually called just "class".
Mapping a font instance
-----------------------
Mapping a font instance involves using a font class (or even several
classes) to build the characters in the font. The characters are built
by scaling, rotating, calculating bezier splines and then actually
drawing the character into the bitmap cache (see further down about
using the bitmap cache). This step is illustrated in figure one by the
small arrow from the font class to the font instance.
Loading a font class from disk
------------------------------
The name of the font class is one of the parts of the TextAttr
structure (or TextVAttr). This name is used to locate a FontContents
file, i.e. a description of font files that are grouped under the
class name. These FontContents files are normally found under the
logically assigned directory FONTS:, and have the file name extension
".font". This relation between the TextAttr structure and the
FontContents file is illustrated in figure 1. This is all according to
the standard diskfont library.
The vfont library will use the TextAttr and the FontContents file when
it decides which font file to load. The FontContents file may contain
some extra information about the file format of a font. This is an
extension that is specific to the vfont library (which is compatible
with the way that the diskfont library uses the FontContents files).
The library will finally open a XDF-library that understands that specific
font file format. The XDF-library will load the font class and make it
available to the vfont library (see figure 1).
The reverse process is done when a font class is stored on disk.
Mapping and Caching a Font
==========================
Mapping a character, i.e. calculating the appearance of it, is a very
time consuming operation. The vfont library will attempt to reduce
that time by only mapping a font when it is absolutely necessary.
Characters are mapped right before they are printed on a rastport if
they was previously unmapped. This implies that the calculated vectors
of a character are cached and reused instead of being created every
time they are needed. This will save times, since unused character
will never be mapped and each character that is used will only be
mapped once.
Using the scaled, rotated and otherwise prepared vectors of the mapped
characters is also a expensive operation. The library will attempt to
reduce that needed cpu time by drawing that characters into a private
bitmap cache. Drawing a character a second time can then be done by
blitting the image of that character directly from the bitmap cache to
the rastport. This will increase the character rendering speed as much
as 100 times for complicated characters.
The bitmap cache are not always used due to memory requirements.
Having a bitmap cache for a 80x100 pixel font that has 100 characters
requires 100K chip memory (or more if it is a color font), which might
be a bit too much for many Amigas. The bitmap cache will be used for
as many characters as it will fit, which in most cases will be enough
since a plain text consists, at a large extent, of a small number of
different character.
A program can prepare a font by explicitly mapping some character and
thus making sure that they are bitmap cached, by using the MakeChar
function. The library will do this automatically in a
first-used-first-cached fashion if the program doesn't explicitly maps
the characters, which gives a fairly good result since commonly used
characters will have a good chance of being used while there still are
space left in the bitmap cache.
Memory Management
=================
Private Memory Pool
-------------------
The memory management of the vfont library is quite extensive and
interesting in many ways, so I will mention some words about it. The
internal data structure that are used to represent the font classes and
the instances consists of many small pieces of data that dynamically
grows and shrinks in number and size.
Using the main memory allocation functions AllocMem/FreeMem would very
quickly lead to a very badly fragmented memory, e.g. the memory will
be divided into so small pieces so that programs that requires large
continues memory blocks will fail even though the total amount of free
memory might be sufficiently high.
This problem is solved by maintaining a private memory pool, so that
the library will allocate fewer and much larger blocks of memory at the
time. The library will then make the frequent and small allocation
from this memory pool. A side effect is that allocation and
deallocation gets a bit faster since a average memory allocation or
deallocation don't have to bother with the memory management of the
whole system, but only with the memory pool managed by the library.
This type of memory management is described in the exec manual, though
it is not described in detail. The memory pool is implemented as a
special list, called MemChunk, with a list root called MemHeader. The
pool if filled by calling AllocMem when needed, and used by calling
Allocate.
Automatic Garbage Collection
----------------------------
Another aspect of the memory management is that the library will use a
lot of memory if you let it. Purging unused fonts and classes might be
necessary after a while. This is done entirely automatically by the
library when it is needed, i.e. when another task tries to allocate
(AllocMem or AllocEntry) more memory than available.
The exec library will at those occasions try and expunge unused
libraries. The vfont library will seem to be unused, so the exec
library will call the expunge function of the vfont library. The vfont
library will not expunge itself if it in fact is used by programs, but
it will then be polite and purge unused classes and fonts and release
that memory back to the system.