636 lines
24 KiB
Plaintext
636 lines
24 KiB
Plaintext
|
|
How FreeType's rasterizer work
|
|
|
|
by David Turner
|
|
|
|
Revised 2007-Feb-01
|
|
|
|
|
|
This file is an attempt to explain the internals of the FreeType
|
|
rasterizer. The rasterizer is of quite general purpose and could
|
|
easily be integrated into other programs.
|
|
|
|
|
|
I. Introduction
|
|
|
|
II. Rendering Technology
|
|
1. Requirements
|
|
2. Profiles and Spans
|
|
a. Sweeping the Shape
|
|
b. Decomposing Outlines into Profiles
|
|
c. The Render Pool
|
|
d. Computing Profiles Extents
|
|
e. Computing Profiles Coordinates
|
|
f. Sweeping and Sorting the Spans
|
|
|
|
|
|
I. Introduction
|
|
===============
|
|
|
|
A rasterizer is a library in charge of converting a vectorial
|
|
representation of a shape into a bitmap. The FreeType rasterizer
|
|
has been originally developed to render the glyphs found in
|
|
TrueType files, made up of segments and second-order Béziers.
|
|
Meanwhile it has been extended to render third-order Bézier curves
|
|
also. This document is an explanation of its design and
|
|
implementation.
|
|
|
|
While these explanations start from the basics, a knowledge of
|
|
common rasterization techniques is assumed.
|
|
|
|
|
|
II. Rendering Technology
|
|
========================
|
|
|
|
1. Requirements
|
|
---------------
|
|
|
|
We assume that all scaling, rotating, hinting, etc., has been
|
|
already done. The glyph is thus described by a list of points in
|
|
the device space.
|
|
|
|
- All point coordinates are in the 26.6 fixed float format. The
|
|
used orientation is:
|
|
|
|
|
|
^ y
|
|
| reference orientation
|
|
|
|
|
*----> x
|
|
0
|
|
|
|
|
|
`26.6' means that 26 bits are used for the integer part of a
|
|
value and 6 bits are used for the fractional part.
|
|
Consequently, the `distance' between two neighbouring pixels is
|
|
64 `units' (1 unit = 1/64th of a pixel).
|
|
|
|
Note that, for the rasterizer, pixel centers are located at
|
|
integer coordinates. The TrueType bytecode interpreter,
|
|
however, assumes that the lower left edge of a pixel (which is
|
|
taken to be a square with a length of 1 unit) has integer
|
|
coordinates.
|
|
|
|
|
|
^ y ^ y
|
|
| |
|
|
| (1,1) | (0.5,0.5)
|
|
+-----------+ +-----+-----+
|
|
| | | | |
|
|
| | | | |
|
|
| | | o-----+-----> x
|
|
| | | (0,0) |
|
|
| | | |
|
|
o-----------+-----> x +-----------+
|
|
(0,0) (-0.5,-0.5)
|
|
|
|
TrueType bytecode interpreter FreeType rasterizer
|
|
|
|
|
|
A pixel line in the target bitmap is called a `scanline'.
|
|
|
|
- A glyph is usually made of several contours, also called
|
|
`outlines'. A contour is simply a closed curve that delimits an
|
|
outer or inner region of the glyph. It is described by a series
|
|
of successive points of the points table.
|
|
|
|
Each point of the glyph has an associated flag that indicates
|
|
whether it is `on' or `off' the curve. Two successive `on'
|
|
points indicate a line segment joining the two points.
|
|
|
|
One `off' point amidst two `on' points indicates a second-degree
|
|
(conic) Bézier parametric arc, defined by these three points
|
|
(the `off' point being the control point, and the `on' ones the
|
|
start and end points). Similarly, a third-degree (cubic) Bézier
|
|
curve is described by four points (two `off' control points
|
|
between two `on' points).
|
|
|
|
Finally, for second-order curves only, two successive `off'
|
|
points forces the rasterizer to create, during rendering, an
|
|
`on' point amidst them, at their exact middle. This greatly
|
|
facilitates the definition of successive Bézier arcs.
|
|
|
|
The parametric form of a second-order Bézier curve is:
|
|
|
|
P(t) = (1-t)^2*P1 + 2*t*(1-t)*P2 + t^2*P3
|
|
|
|
(P1 and P3 are the end points, P2 the control point.)
|
|
|
|
The parametric form of a third-order Bézier curve is:
|
|
|
|
P(t) = (1-t)^3*P1 + 3*t*(1-t)^2*P2 + 3*t^2*(1-t)*P3 + t^3*P4
|
|
|
|
(P1 and P4 are the end points, P2 and P3 the control points.)
|
|
|
|
For both formulae, t is a real number in the range [0..1].
|
|
|
|
Note that the rasterizer does not use these formulae directly.
|
|
They exhibit, however, one very useful property of Bézier arcs:
|
|
Each point of the curve is a weighted average of the control
|
|
points.
|
|
|
|
As all weights are positive and always sum up to 1, whatever the
|
|
value of t, each arc point lies within the triangle (polygon)
|
|
defined by the arc's three (four) control points.
|
|
|
|
In the following, only second-order curves are discussed since
|
|
rasterization of third-order curves is completely identical.
|
|
|
|
Here some samples for second-order curves.
|
|
|
|
|
|
* # on curve
|
|
* off curve
|
|
__---__
|
|
#-__ _-- -_
|
|
--__ _- -
|
|
--__ # \
|
|
--__ #
|
|
-#
|
|
Two `on' points
|
|
Two `on' points and one `off' point
|
|
between them
|
|
|
|
*
|
|
# __ Two `on' points with two `off'
|
|
\ - - points between them. The point
|
|
\ / \ marked `0' is the middle of the
|
|
- 0 \ `off' points, and is a `virtual
|
|
-_ _- # on' point where the curve passes.
|
|
-- It does not appear in the point
|
|
* list.
|
|
|
|
|
|
2. Profiles and Spans
|
|
---------------------
|
|
|
|
The following is a basic explanation of the _kind_ of computations
|
|
made by the rasterizer to build a bitmap from a vector
|
|
representation. Note that the actual implementation is slightly
|
|
different, due to performance tuning and other factors.
|
|
|
|
However, the following ideas remain in the same category, and are
|
|
more convenient to understand.
|
|
|
|
|
|
a. Sweeping the Shape
|
|
|
|
The best way to fill a shape is to decompose it into a number of
|
|
simple horizontal segments, then turn them on in the target
|
|
bitmap. These segments are called `spans'.
|
|
|
|
__---__
|
|
_-- -_
|
|
_- -
|
|
- \
|
|
/ \
|
|
/ \
|
|
| \
|
|
|
|
__---__ Example: filling a shape
|
|
_----------_ with spans.
|
|
_--------------
|
|
----------------\
|
|
/-----------------\ This is typically done from the top
|
|
/ \ to the bottom of the shape, in a
|
|
| | \ movement called a `sweep'.
|
|
V
|
|
|
|
__---__
|
|
_----------_
|
|
_--------------
|
|
----------------\
|
|
/-----------------\
|
|
/-------------------\
|
|
|---------------------\
|
|
|
|
|
|
In order to draw a span, the rasterizer must compute its
|
|
coordinates, which are simply the x coordinates of the shape's
|
|
contours, taken on the y scanlines.
|
|
|
|
|
|
/---/ |---| Note that there are usually
|
|
/---/ |---| several spans per scanline.
|
|
| /---/ |---|
|
|
| /---/_______|---| When rendering this shape to the
|
|
V /----------------| current scanline y, we must
|
|
/-----------------| compute the x values of the
|
|
a /----| |---| points a, b, c, and d.
|
|
- - - * * - - - - * * - - y -
|
|
/ / b c| |d
|
|
|
|
|
|
/---/ |---|
|
|
/---/ |---| And then turn on the spans a-b
|
|
/---/ |---| and c-d.
|
|
/---/_______|---|
|
|
/----------------|
|
|
/-----------------|
|
|
a /----| |---|
|
|
- - - ####### - - - - ##### - - y -
|
|
/ / b c| |d
|
|
|
|
|
|
b. Decomposing Outlines into Profiles
|
|
|
|
For each scanline during the sweep, we need the following
|
|
information:
|
|
|
|
o The number of spans on the current scanline, given by the
|
|
number of shape points intersecting the scanline (these are
|
|
the points a, b, c, and d in the above example).
|
|
|
|
o The x coordinates of these points.
|
|
|
|
x coordinates are computed before the sweep, in a phase called
|
|
`decomposition' which converts the glyph into *profiles*.
|
|
|
|
Put it simply, a `profile' is a contour's portion that can only
|
|
be either ascending or descending, i.e., it is monotonic in the
|
|
vertical direction (we also say y-monotonic). There is no such
|
|
thing as a horizontal profile, as we shall see.
|
|
|
|
Here are a few examples:
|
|
|
|
|
|
this square
|
|
1 2
|
|
---->---- is made of two
|
|
| | | |
|
|
| | profiles | |
|
|
^ v ^ + v
|
|
| | | |
|
|
| | | |
|
|
----<----
|
|
|
|
up down
|
|
|
|
|
|
this triangle
|
|
|
|
P2 1 2
|
|
|
|
|\ is made of two | \
|
|
^ | \ \ | \
|
|
| | \ \ profiles | \ |
|
|
| | \ v ^ | \ |
|
|
| \ | | + \ v
|
|
| \ | | \
|
|
P1 ---___ \ ---___ \
|
|
---_\ ---_ \
|
|
<--__ P3 up down
|
|
|
|
|
|
|
|
A more general contour can be made of more than two profiles:
|
|
|
|
__ ^
|
|
/ | / ___ / |
|
|
/ | / | / | / |
|
|
| | / / => | v / /
|
|
| | | | | | ^ |
|
|
^ | |___| | | ^ + | + | + v
|
|
| | | v | |
|
|
| | | up |
|
|
|___________| | down |
|
|
|
|
<-- up down
|
|
|
|
|
|
Successive profiles are always joined by horizontal segments
|
|
that are not part of the profiles themselves.
|
|
|
|
For the rasterizer, a profile is simply an *array* that
|
|
associates one horizontal *pixel* coordinate to each bitmap
|
|
*scanline* crossed by the contour's section containing the
|
|
profile. Note that profiles are *oriented* up or down along the
|
|
glyph's original flow orientation.
|
|
|
|
In other graphics libraries, profiles are also called `edges' or
|
|
`edgelists'.
|
|
|
|
|
|
c. The Render Pool
|
|
|
|
FreeType has been designed to be able to run well on _very_
|
|
light systems, including embedded systems with very few memory.
|
|
|
|
A render pool will be allocated once; the rasterizer uses this
|
|
pool for all its needs by managing this memory directly in it.
|
|
The algorithms that are used for profile computation make it
|
|
possible to use the pool as a simple growing heap. This means
|
|
that this memory management is actually quite easy and faster
|
|
than any kind of malloc()/free() combination.
|
|
|
|
Moreover, we'll see later that the rasterizer is able, when
|
|
dealing with profiles too large and numerous to lie all at once
|
|
in the render pool, to immediately decompose recursively the
|
|
rendering process into independent sub-tasks, each taking less
|
|
memory to be performed (see `sub-banding' below).
|
|
|
|
The render pool doesn't need to be large. A 4KByte pool is
|
|
enough for nearly all renditions, though nearly 100% slower than
|
|
a more comfortable 16KByte or 32KByte pool (that was tested with
|
|
complex glyphs at sizes over 500 pixels).
|
|
|
|
|
|
d. Computing Profiles Extents
|
|
|
|
Remember that a profile is an array, associating a _scanline_ to
|
|
the x pixel coordinate of its intersection with a contour.
|
|
|
|
Though it's not exactly how the FreeType rasterizer works, it is
|
|
convenient to think that we need a profile's height before
|
|
allocating it in the pool and computing its coordinates.
|
|
|
|
The profile's height is the number of scanlines crossed by the
|
|
y-monotonic section of a contour. We thus need to compute these
|
|
sections from the vectorial description. In order to do that,
|
|
we are obliged to compute all (local and global) y extrema of
|
|
the glyph (minima and maxima).
|
|
|
|
|
|
P2 For instance, this triangle has only
|
|
two y-extrema, which are simply
|
|
|\
|
|
| \ P2.y as a vertical maximum
|
|
| \ P3.y as a vertical minimum
|
|
| \
|
|
| \ P1.y is not a vertical extremum (though
|
|
| \ it is a horizontal minimum, which we
|
|
P1 ---___ \ don't need).
|
|
---_\
|
|
P3
|
|
|
|
|
|
Note that the extrema are expressed in pixel units, not in
|
|
scanlines. The triangle's height is certainly (P3.y-P2.y+1)
|
|
pixel units, but its profiles' heights are computed in
|
|
scanlines. The exact conversion is simple:
|
|
|
|
- min scanline = FLOOR ( min y )
|
|
- max scanline = CEILING( max y )
|
|
|
|
A problem arises with Bézier Arcs. While a segment is always
|
|
necessarily y-monotonic (i.e., flat, ascending, or descending),
|
|
which makes extrema computations easy, the ascent of an arc can
|
|
vary between its control points.
|
|
|
|
|
|
P2
|
|
*
|
|
# on curve
|
|
* off curve
|
|
__-x--_
|
|
_-- -_
|
|
P1 _- - A non y-monotonic Bézier arc.
|
|
# \
|
|
- The arc goes from P1 to P3.
|
|
\
|
|
\ P3
|
|
#
|
|
|
|
|
|
We first need to be able to easily detect non-monotonic arcs,
|
|
according to their control points. I will state here, without
|
|
proof, that the monotony condition can be expressed as:
|
|
|
|
P1.y <= P2.y <= P3.y for an ever-ascending arc
|
|
|
|
P1.y >= P2.y >= P3.y for an ever-descending arc
|
|
|
|
with the special case of
|
|
|
|
P1.y = P2.y = P3.y where the arc is said to be `flat'.
|
|
|
|
As you can see, these conditions can be very easily tested.
|
|
They are, however, extremely important, as any arc that does not
|
|
satisfy them necessarily contains an extremum.
|
|
|
|
Note also that a monotonic arc can contain an extremum too,
|
|
which is then one of its `on' points:
|
|
|
|
|
|
P1 P2
|
|
#---__ * P1P2P3 is ever-descending, but P1
|
|
-_ is an y-extremum.
|
|
-
|
|
---_ \
|
|
-> \
|
|
\ P3
|
|
#
|
|
|
|
|
|
Let's go back to our previous example:
|
|
|
|
|
|
P2
|
|
*
|
|
# on curve
|
|
* off curve
|
|
__-x--_
|
|
_-- -_
|
|
P1 _- - A non-y-monotonic Bézier arc.
|
|
# \
|
|
- Here we have
|
|
\ P2.y >= P1.y &&
|
|
\ P3 P2.y >= P3.y (!)
|
|
#
|
|
|
|
|
|
We need to compute the vertical maximum of this arc to be able
|
|
to compute a profile's height (the point marked by an `x'). The
|
|
arc's equation indicates that a direct computation is possible,
|
|
but we rely on a different technique, which use will become
|
|
apparent soon.
|
|
|
|
Bézier arcs have the special property of being very easily
|
|
decomposed into two sub-arcs, which are themselves Bézier arcs.
|
|
Moreover, it is easy to prove that there is at most one vertical
|
|
extremum on each Bézier arc (for second-degree curves; similar
|
|
conditions can be found for third-order arcs).
|
|
|
|
For instance, the following arc P1P2P3 can be decomposed into
|
|
two sub-arcs Q1Q2Q3 and R1R2R3:
|
|
|
|
|
|
P2
|
|
*
|
|
# on curve
|
|
* off curve
|
|
|
|
|
|
original Bézier arc P1P2P3.
|
|
__---__
|
|
_-- --_
|
|
_- -_
|
|
- -
|
|
/ \
|
|
/ \
|
|
# #
|
|
P1 P3
|
|
|
|
|
|
|
|
P2
|
|
*
|
|
|
|
|
|
|
|
Q3 Decomposed into two subarcs
|
|
Q2 R2 Q1Q2Q3 and R1R2R3
|
|
* __-#-__ *
|
|
_-- --_
|
|
_- R1 -_ Q1 = P1 R3 = P3
|
|
- - Q2 = (P1+P2)/2 R2 = (P2+P3)/2
|
|
/ \
|
|
/ \ Q3 = R1 = (Q2+R2)/2
|
|
# #
|
|
Q1 R3 Note that Q2, R2, and Q3=R1
|
|
are on a single line which is
|
|
tangent to the curve.
|
|
|
|
|
|
We have then decomposed a non-y-monotonic Bézier curve into two
|
|
smaller sub-arcs. Note that in the above drawing, both sub-arcs
|
|
are monotonic, and that the extremum is then Q3=R1. However, in
|
|
a more general case, only one sub-arc is guaranteed to be
|
|
monotonic. Getting back to our former example:
|
|
|
|
|
|
Q2
|
|
*
|
|
|
|
__-x--_ R1
|
|
_-- #_
|
|
Q1 _- Q3 - R2
|
|
# \ *
|
|
-
|
|
\
|
|
\ R3
|
|
#
|
|
|
|
|
|
Here, we see that, though Q1Q2Q3 is still non-monotonic, R1R2R3
|
|
is ever descending: We thus know that it doesn't contain the
|
|
extremum. We can then re-subdivide Q1Q2Q3 into two sub-arcs and
|
|
go on recursively, stopping when we encounter two monotonic
|
|
subarcs, or when the subarcs become simply too small.
|
|
|
|
We will finally find the vertical extremum. Note that the
|
|
iterative process of finding an extremum is called `flattening'.
|
|
|
|
|
|
e. Computing Profiles Coordinates
|
|
|
|
Once we have the height of each profile, we are able to allocate
|
|
it in the render pool. The next task is to compute coordinates
|
|
for each scanline.
|
|
|
|
In the case of segments, the computation is straightforward,
|
|
using the Euclidean algorithm (also known as Bresenham).
|
|
However, for Bézier arcs, the job is a little more complicated.
|
|
|
|
We assume that all Béziers that are part of a profile are the
|
|
result of flattening the curve, which means that they are all
|
|
y-monotonic (ascending or descending, and never flat). We now
|
|
have to compute the intersections of arcs with the profile's
|
|
scanlines. One way is to use a similar scheme to flattening
|
|
called `stepping'.
|
|
|
|
|
|
Consider this arc, going from P1 to
|
|
--------------------- P3. Suppose that we need to
|
|
compute its intersections with the
|
|
drawn scanlines. As already
|
|
--------------------- mentioned this can be done
|
|
directly, but the involved
|
|
* P2 _---# P3 algorithm is far too slow.
|
|
------------- _-- --
|
|
_-
|
|
_/ Instead, it is still possible to
|
|
---------/----------- use the decomposition property in
|
|
/ the same recursive way, i.e.,
|
|
| subdivide the arc into subarcs
|
|
------|-------------- until these get too small to cross
|
|
| more than one scanline!
|
|
|
|
|
-----|--------------- This is very easily done using a
|
|
| rasterizer-managed stack of
|
|
| subarcs.
|
|
# P1
|
|
|
|
|
|
f. Sweeping and Sorting the Spans
|
|
|
|
Once all our profiles have been computed, we begin the sweep to
|
|
build (and fill) the spans.
|
|
|
|
As both the TrueType and Type 1 specifications use the winding
|
|
fill rule (but with opposite directions), we place, on each
|
|
scanline, the present profiles in two separate lists.
|
|
|
|
One list, called the `left' one, only contains ascending
|
|
profiles, while the other `right' list contains the descending
|
|
profiles.
|
|
|
|
As each glyph is made of closed curves, a simple geometric
|
|
property ensures that the two lists contain the same number of
|
|
elements.
|
|
|
|
Creating spans is thus straightforward:
|
|
|
|
1. We sort each list in increasing horizontal order.
|
|
|
|
2. We pair each value of the left list with its corresponding
|
|
value in the right list.
|
|
|
|
|
|
/ / | | For example, we have here
|
|
/ / | | four profiles. Two of
|
|
>/ / | | | them are ascending (1 &
|
|
1// / ^ | | | 2 3), while the two others
|
|
// // 3| | | v are descending (2 & 4).
|
|
/ //4 | | | On the given scanline,
|
|
a / /< | | the left list is (1,3),
|
|
- - - *-----* - - - - *---* - - y - and the right one is
|
|
/ / b c| |d (4,2) (sorted).
|
|
|
|
There are then two spans, joining
|
|
1 to 4 (i.e. a-b) and 3 to 2
|
|
(i.e. c-d)!
|
|
|
|
|
|
Sorting doesn't necessarily take much time, as in 99 cases out
|
|
of 100, the lists' order is kept from one scanline to the next.
|
|
We can thus implement it with two simple singly-linked lists,
|
|
sorted by a classic bubble-sort, which takes a minimum amount of
|
|
time when the lists are already sorted.
|
|
|
|
A previous version of the rasterizer used more elaborate
|
|
structures, like arrays to perform `faster' sorting. It turned
|
|
out that this old scheme is not faster than the one described
|
|
above.
|
|
|
|
Once the spans have been `created', we can simply draw them in
|
|
the target bitmap.
|
|
|
|
------------------------------------------------------------------------
|
|
|
|
Copyright 2003-2017 by
|
|
David Turner, Robert Wilhelm, and Werner Lemberg.
|
|
|
|
This file is part of the FreeType project, and may only be used,
|
|
modified, and distributed under the terms of the FreeType project
|
|
license, LICENSE.TXT. By continuing to use, modify, or distribute this
|
|
file you indicate that you have read the license and understand and
|
|
accept it fully.
|
|
|
|
|
|
--- end of raster.txt ---
|
|
|
|
Local Variables:
|
|
coding: utf-8
|
|
End:
|