Path Construction
[Drawing Functions]

Typedefs
typedef int	COORD_T
Enumerations
enum	{ NONE, PIE, CHORD }
Functions
void	fltk::addarc (float x, float y, float w, float h, float a1, float a2)
void	fltk::addchord (const Rectangle &r, float a, float a2)
void	fltk::addcurve (float, float, float, float, float, float, float, float)
void	fltk::addpie (const Rectangle &r, float a, float a2)
void	fltk::addvertex (int x, int y)
void	fltk::addvertex (float x, float y)
void	fltk::addvertices (int n, const int v[][2])
void	fltk::addvertices (int n, const float v[][2])
void	fltk::addvertices_transformed (int n, const float v[][2])
void	fltk::closepath ()
void	fltk::drawpoints ()
void	fltk::fillpath ()
void	fltk::fillstrokepath (Color)
void	fltk::newpath ()
void	fltk::strokepath ()
Variables
enum { ... }	circle_type

---

Detailed Description

These functions let you draw arbitrary shapes with 2-D linear transformations. The functionality matches that found in Adobe® PostScript^TM. On both X and WIN32 the transformed vertices are rounded to integers before drawing the line segments, this severely limits the accuracy of these functions for complex graphics, so use OpenGL when greater accuracy and/or performance is required.

Unlike PostScript^TM the path is cleared after you draw it. Instead fltk provides operators that do multiple operations on the same path, such as fillstrokepath().

---

Function Documentation

void newpath (   )

Clear the current "path". This is normally done by fltk::fillpath() or any other drawing command.

void addvertex (  float  X, float  Y )

Add a single vertex to the current path. (If you are familiar with PostScript, this does a "moveto" if the path is clear or fltk::closepath was done last, otherwise it does a "lineto").

void addvertex (  int  X, int  Y )

This integer version is provided because it is much faster than the floating-point version. However C++ will not "resolve" which one you want to call if you try passing doubles as arguments. To get it to compile, make sure you cast the arguments to float (add 'f' after floating-point constants). Use the 'f' versions (ie sinf(), cosf(), etc) of the math functions from <fltk/math.h> to produce floats and get maximum calculation speed.

void addvertices (  int  n, const float  array[][2] )

Add a whole set of vertices to the current path. This is much faster than calling fltk::addvertex once for each point.

void addvertices (  int  n, const int  array[][2] )

Add a whole set of integer vertices to the current path.

void addvertices_transformed (  int  n, const float  array[][2] )

Adds a whole set of vertcies that have been produced from values returned by fltk::transform(). This is how curve() and arc() are implemented. Not implemented if Cairo is in use!

void addcurve (  float  x0, float  y0, float  x1, float  y1, float  x2, float  y2, float  x3, float  y3 )

Add a series of points on a Bezier spline to the path. The curve ends (and two of the points) are at x,y and x3,y3. The "handles" are at x1,y1 and x2,y2.

void addarc (  float  l, float  t, float  w, float  h, float  start, float  end )

Add a series of points to the current path on the arc of an ellipse. The ellipse in inscribed in the l,t,w,h rectangle, and the start and end angles are measured in degrees counter-clockwise from 3 o'clock, 45 points at the upper-right corner of the rectangle. If end is less than start then it draws the arc in a clockwise direction.

void addpie (  const Rectangle &  r, float  start, float  end )

Add a pie-shaped closed piece to the path, inscribed in the rectangle so if it is stroked with the default line width it exactly fills the rectangle (this is slightly smaller than addarc() will draw). If you want a full circle use addchord(). This tries to take advantage of the primitive calls provided by Xlib and GDI32. Limitations are that you can only draw one per path, that rotated coordinates don't work, and doing anything other than fillpath() will produce unpredictable results. See also: addchord()

void addchord (  const Rectangle &  r, float  start, float  end )

Add an isolated circular arc to the path. It is inscribed in the rectangle so if it is stroked with the default line width it exactly fills the rectangle (this is slightly smaller than addarc() will draw). If the angles are 0 and 360 a closed circle is added. This tries to take advantage of the primitive calls provided by Xlib and GDI32. Limitations are that you can only draw one, a rotated current transform does not work, and whether stroke of a closed version draws the straight edge is indeterminate.

void closepath (   )

Similar to drawing another vertex back at the starting point, but fltk knows the path is closed. The next fltk::vertex will start a new disconnected part of the shape. It is harmless to call fltk::closepath() several times in a row, or to call it before the first point. Sections with less than 3 points in them will not draw anything when filled.

void drawpoints (   )

Draw a point (one pixel) for every vertex in the path, then clear the path. In theory the line_style() should affect how big the points are, but I don't think that works on X.

void strokepath (   )

Draw a line between all the points in the path (see fltk::line_style() for ways to set the thicknesss and dot pattern of the line), then clear the path.

void fillpath (   )

Does fltk::closepath() and then fill with the current color, and then clear the path. For portability, you should only draw polygons that appear the same whether "even/odd" or "non-zero" winding rules are used to fill them. This mostly means that holes should be drawn in the opposite direction of the outside. Warning: result is somewhat different on X and Win32! Use fillstrokepath() to make matching shapes. In my opinion X is correct, we may change the Win32 version to match in the future, perhaps by making the current pen invisible?

void fillstrokepath (  Color  color  )

Does fltk::fill(), then sets the current color to linecolor and does fltk::stroke with the same closed path, and then clears the path. This seems to produce very similar results on X and Win32. Also it takes advantage of a single GDI32 call that does this and should be faster.

---