Here's an effort to document some of the academic work that was
referenced during the implementation of cairo. It is presented in the
context of operations as they would be performed by either
cairo_stroke() or cairo_fill():
Given a Bézier path, approximate it with line segments:
"The deCasteljau algorithm Outillages methodes calcul", P de Casteljau, technical report, Andre Citroen Automobiles SA, Paris, 1959.
That technical report might be "hard" to find, but fortunately this algorithm will be described in any reasonable textbook on computational geometry. Two that have been recommended by cairo contributors are:
"Computational Geometry, Algorithms and Applications", M. de Berg, M. van Kreveld, M. Overmars, M. Schwarzkopf; Springer-Verlag, ISBN: 3-540-65620-0.
"Computational Geometry in C (Second Edition)", Joseph O'Rourke, Cambridge University Press, ISBN 0521640105.
An extension to the original implementation is to switch to an iterative solver:
"Fast, precise flattening of cubic Bézier path and offset curves", Thomas F. Hain, Athar L. Ahmad, Sri Venkat R. Racherla, David D. Langan.
Then, if stroking, construct a polygonal representation of the pen approximating a circle (if filling skip three steps):
- "Good approximation of circles by curvature-continuous Bezier curves", Tor Dokken and Morten Daehlen, Computer Aided Geometric Design 8 (1990) 22-41.
Add points to that pen based on the initial/final path faces and take the convex hull:
Convex hull algorithm
Again, see your favorite computational geometry textbook. Should cite the name of the algorithm cairo uses here, if it has a name.
Now, "convolve" the "tracing" of the pen with the tracing of the path:
- "A Kinetic Framework for Computational Geometry", Leonidas J. Guibas, Lyle Ramshaw, and Jorge Stolfi, Proceedings of the 24th IEEE Annual Symposium on Foundations of Computer Science (FOCS), November 1983, 100-111.
The result of the convolution is a polygon that must be filled. A fill operations begins here. We use a very conventional Bentley-Ottmann pass for computing the intersections, informed by some hints on robust implementation courtesy of John Hobby:
- John D. Hobby, Practical Segment Intersection with Finite Precision Output, Computation Geometry Theory and Applications, 13(4), 1999. http://cm.bell-labs.com/who/hobby/93_2-27.pdf
Hobby's primary contribution in that paper is his "tolerance square" algorithm for robustness against edges being "bent" due to restricting intersection coordinates to the grid available by finite-precision arithmetic. This is one algorithm we have not implemented yet.
We use a data-structure called Skiplists in the our implementation of Bentley-Ottmann:
- W. Pugh, Skip Lists: a Probabilistic Alternative to Balanced Trees, Communications of the ACM, vol. 33, no. 6, pp.668-676, 1990. http://citeseer.ist.psu.edu/pugh90skip.html
From the result of the intersection-finding pass, we are currently computing a tessellation of trapezoids, (the exact manner is undergoing some work right now with some important speedup), but we may want to rasterize directly from those edges at some point.
Given the set of tessellated trapezoids, we currently execute a straightforward, (and slow), point-sampled rasterization, (and currently with a near-pessimal regular 15x17 grid).
We've now computed a mask which gets fed along with the source and destination into cairo's fundamental rendering equation. The most basic form of this equation is:
destination = (source IN mask) OP destination
with the restriction that no part of the destination outside the current clip region is affected. In this equation, IN refers to the Porter-Duff "in" operation, while OP refers to a any user-selected Porter-Duff operator:
- T. Porter & T. Duff, Compositing Digital Images Computer Graphics Volume 18, Number 3 July 1984 pp 253-259 http://keithp.com/~keithp/porterduff/p253-porter.pdf
However, sometimes we do not rasterise at all and are able to write directly to a vector surface. For the capabilities of each you need to read the individual reference manuals:
PostScript: