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
Encoding:
Text File  |  1991-06-09  |  8.8 KB  |  200 lines
  1.  
  2.  
  3.                 TECHNICAL NOTES ABOUT THE VFONT LIBRARY
  4.                 
  5.  
  6.  
  7. Copyright 1991 by Michael Jansson. All Rights Reserved.
  8.  
  9. This file is a part of the vfont distribution.  It may only be
  10. distributed in companion with the other parts of the vfont
  11. distribution.  It may be freely distributed for non-profitable
  12. purposes only.
  13.  
  14.  
  15.  
  16.  
  17. Introduction
  18. ============
  19. This file contains technical information about the design and the
  20. functionality of the vfont libraries.  It will not give any detailed
  21. information, but a more abstract overview of the libraries.  It is a
  22. good idea to read this text if you are planning to use the library as
  23. an application programmer, or if you are interested in knowing how the
  24. vfont library works.
  25.  
  26. The next step of an application programmer ought to be to look at the
  27. included examples, and then finally use the autodocs when he/she
  28. actually gets around to do some implementation work with the libraries.
  29.  
  30.  
  31. Document History
  32. ================
  33. This is the first version of this document, dated Tue Apr 30 01:05:11
  34. 1991.  I might have missed some important aspects about the vfont
  35. libraries, or possibly described some aspects of the library too
  36. superficially.  Get in touch with me if you are experiences such flaws
  37. so that I can improve the readability of the document.
  38.  
  39.  
  40. Creating a Font
  41. ===============
  42.  
  43.  
  44.  (Font Contents file)      (A specific font format file)
  45.           ^  ^                          |
  46.           |  |                          |
  47.           |  |                          |   
  48.           |  |                         \|/
  49.           |  +------------------------->X<==[XDF library]
  50.           |                            /|\
  51.           |                             |
  52.           |                             V
  53.           +-------->(TextVAttr)<-->(Font Class)
  54.                                         |
  55.                                         |
  56.                                         V
  57.                                   (Font Instance)
  58.  
  59.  
  60. [Figure 1: The relation between vfont data structures.]
  61.  
  62.  
  63. Creating a font involves several steps.  These steps are takes when
  64. either the OpenVFont or the OpenBFont function is called.  These
  65. functions takes a parameter that describes the characteristics of the
  66. desired font, such as size and name.  Such description can either be a
  67. "struct TextAttr" or a "struct TextVAttr" which is an extension of the
  68. first structure.  This is a perfect analogy to the graphics library
  69. function OpenFont and the diskfont function OpenDiskFont, which takes a
  70. TextAttr structure as a parameter.  
  71.  
  72. The library will scan through resident font classes, i.e.  font
  73. templates that has previously been loaded from disk, to see if there is
  74. one that fits the description.  It will attempt to load a font class
  75. from a file on disk if there is no one that matches the given
  76. description.  The font class is then used to create a font instance, by
  77. "mapping" it.  A font class may be used to create several new font
  78. instances, and a font instance may be used by several programs.  A font
  79. instance is usually just called "font" for short, and a font class is
  80. usually called just "class".
  81.  
  82.  
  83. Mapping a font instance
  84. -----------------------
  85. Mapping a font instance involves using a font class (or even several
  86. classes) to build the characters in the font.  The characters are built
  87. by scaling, rotating, calculating bezier splines and then actually
  88. drawing the character into the bitmap cache (see further down about
  89. using the bitmap cache).  This step is illustrated in figure one by the
  90. small arrow from the font class to the font instance.
  91.  
  92. Loading a font class from disk
  93. ------------------------------
  94. The name of the font class is one of the parts of the TextAttr
  95. structure (or TextVAttr).  This name is used to locate a FontContents
  96. file, i.e.  a description of font files that are grouped under the
  97. class name.  These FontContents files are normally found under the
  98. logically assigned directory FONTS:, and have the file name extension
  99. ".font".  This relation between the TextAttr structure and the
  100. FontContents file is illustrated in figure 1.  This is all according to
  101. the standard diskfont library.
  102.  
  103. The vfont library will use the TextAttr and the FontContents file when
  104. it decides which font file to load.  The FontContents file may contain
  105. some extra information about the file format of a font.  This is an
  106. extension that is specific to the vfont library (which is compatible
  107. with the way that the diskfont library uses the FontContents files).
  108.  
  109. The library will finally open a XDF-library that understands that specific
  110. font file format.  The XDF-library will load the font class and make it
  111. available to the vfont library (see figure 1).
  112.  
  113. The reverse process is done when a font class is stored on disk.
  114.  
  115.  
  116. Mapping and Caching a Font
  117. ==========================
  118. Mapping a character, i.e.  calculating the appearance of it, is a very
  119. time consuming operation.  The vfont library will attempt to reduce
  120. that time by only mapping a font when it is absolutely necessary.
  121. Characters are mapped right before they are printed on a rastport if
  122. they was previously unmapped.  This implies that the calculated vectors
  123. of a character are cached and reused instead of being created every
  124. time they are needed.  This will save times, since unused character
  125. will never be mapped and each character that is used will only be
  126. mapped once.
  127.  
  128. Using the scaled, rotated and otherwise prepared vectors of the mapped
  129. characters is also a expensive operation.  The library will attempt to
  130. reduce that needed cpu time by drawing that characters into a private
  131. bitmap cache.  Drawing a character a second time can then be done by
  132. blitting the image of that character directly from the bitmap cache to
  133. the rastport.  This will increase the character rendering speed as much
  134. as 100 times for complicated characters.
  135.  
  136. The bitmap cache are not always used due to memory requirements.
  137. Having a bitmap cache for a 80x100 pixel font that has 100 characters
  138. requires 100K chip memory (or more if it is a color font), which might
  139. be a bit too much for many Amigas.  The bitmap cache will be used for
  140. as many characters as it will fit, which in most cases will be enough
  141. since a plain text consists, at a large extent, of a small number of
  142. different character.  
  143.  
  144. A program can prepare a font by explicitly mapping some character and
  145. thus making sure that they are bitmap cached, by using the MakeChar
  146. function.  The library will do this automatically in a
  147. first-used-first-cached fashion if the program doesn't explicitly maps
  148. the characters, which gives a fairly good result since commonly used
  149. characters will have a good chance of being used while there still are
  150. space left in the bitmap cache.
  151.  
  152.  
  153.  
  154. Memory Management
  155. =================
  156.  
  157.  
  158. Private Memory Pool
  159. -------------------
  160. The memory management of the vfont library is quite extensive and
  161. interesting in many ways, so I will mention some words about it.  The
  162. internal data structure that are used to represent the font classes and
  163. the instances consists of many small pieces of data that dynamically
  164. grows and shrinks in number and size.
  165.  
  166. Using the main memory allocation functions AllocMem/FreeMem would very
  167. quickly lead to a very badly fragmented memory, e.g.  the memory will
  168. be divided into so small pieces so that programs that requires large
  169. continues memory blocks will fail even though the total amount of free
  170. memory might be sufficiently high.
  171.  
  172. This problem is solved by maintaining a private memory pool, so that
  173. the library will allocate fewer and much larger blocks of memory at the
  174. time.  The library will then make the frequent and small allocation
  175. from this memory pool.  A side effect is that allocation and
  176. deallocation gets a bit faster since a average memory allocation or
  177. deallocation don't have to bother with the memory management of the
  178. whole system, but only with the memory pool managed by the library.
  179. This type of memory management is described in the exec manual, though
  180. it is not described in detail.  The memory pool is implemented as a
  181. special list, called MemChunk, with a list root called MemHeader.  The
  182. pool if filled by calling AllocMem when needed, and used by calling
  183. Allocate.
  184.  
  185.  
  186. Automatic Garbage Collection
  187. ----------------------------
  188. Another aspect of the memory management is that the library will use a
  189. lot of memory if you let it.  Purging unused fonts and classes might be
  190. necessary after a while.  This is done entirely automatically by the
  191. library when it is needed, i.e.  when another task tries to allocate
  192. (AllocMem or AllocEntry) more memory than available.
  193.  
  194. The exec library will at those occasions try and expunge unused
  195. libraries.  The vfont library will seem to be unused, so the exec
  196. library will call the expunge function of the vfont library.  The vfont
  197. library will not expunge itself if it in fact is used by programs, but
  198. it will then be polite and purge unused classes and fonts and release
  199. that memory back to the system.
  200.