Owen,
Thanks for the nice little example. And an especial thanks for the API
feedback.
I'll break my responses up into different topics. First, the arcs.
On Dec 1, Owen Taylor wrote:
> - No convenience function for circular arcs.
I want to add something here. I'd like some input on what the
interface should look like. I would have loved to have a nice clean
function named XrArcTo that draws a circular arc from the current
point to a specified point, (which becomes the new current
point). This would fit in nicely with XrMoveTo, XrLineTo,
XrCurveTo. But I haven't found a good way to do this.
I've reviewed arc support in several 2D graphics systems and it seems
to me that PostScript takes the right approach[*].
So, I propose the following functions:
XrArc (xc, yc, radius, angle1, angle2); /* angle 2 > angle1 */
XrArcNegative (xc, yc, radius, angle1, angle2); /* angle 2 < angle1 */
XrArcTo (x1, y1, x2, y2, radius);
These are all circular arcs, (it seems elliptical arcs should be easy
enough to generate with XrScale and XrRotate for those who really want
them).
Open questions:
Would XrArcTangent be a better name than XrArcTo?
PostScript arcto returns the computed values of the arc endpoints. How
important is this? Any suggestions for how to do this in the Xr API.
Also, regardless of the parameterization, all Xr functions must be
able to approximate geometry within a user-specified error bound. So,
to implement this, I would like a function that accepts the arc
parameters and the error bound and that returns the number of cubic
bezier splines needed to approximate the arc within that error. Could
anyone easily provide something like that?
As always, feedback is welcome and encouraged.
-Carl
PS. Oh, and how about a convenience function for rectangles? I think
XrRectangle should add a rectangle to the path, (convenience function
for a MoveTo and four LineTo's). I don't see the need now to implement
functions like PostScript's rectstroke/rectfill, (any such
optimization functions can be added later if necessary). I'm inclined
not to add rounded rectangle support.
[*] For any inclined to more reading, here's the results of my review
of arc support in graphics systems:
>From surveying several 2D graphics systems it seems there are two
major means of specifying arcs:
Center Parameterization
-----------------------
Accepts center point, radius, and two angular extents.
This parameterization has a two-way ambiguity (depending on which
direction the arc is drawn).
Endpoint Parameterization
-------------------------
Accept initial and final arc endpoints.
This parameterization has a four-way ambiguity.
Here are what several graphics systems provide and how the ambiguities
are handled:
PDF
---
No arc support.
Core X11 arcs
--------------
Center parameterization. Ambiguity resolved by the sign of the angles,
(I don't know what happens if the sign of the two angles differs).
Java 2D
-------
Center parameterization. I couldn't find a reference explaining how
the ambiguity is resolved, (perhaps arcs are always drawn in the
positive direction?).
SVG
---
Endpoint parameterization. Ambiguity resolved with two flags,
(large arc flag and sweep flag).
PostScript
----------
Center parameterization. Ambiguity resolved with two different
operators, arc and arcn (arc negative).
Note: If current point is defined, also draws line from current point
to initial arc endpoint.
PostScript also provides another more specialized arc function:
arct (point_1, point_2, radius)
arcto (point_1, point_2, radius)
arct specifies a circular arc that fits within and tangent to a
polygon formed by the current point, point_1, and point_2. This is
quite similar to the way that splines are specified. An important
difference is that the endpoints of the arc are not provided as
explicit arguments, but are implicit given the tangents and the
radius. For this reason, the arcto flavor is also provided. It
constructs the same arc as arct, but it also returns the two endpoints
of the arc.
arct cannot be used as a general arc function since it will not draw
arcs with extents greater than 180 degrees, (so it can't be used to
draw a complete circle). But, this is a very handy operator for doing
things such as rounded corners on rectangles.
Conclusions
-----------
Center parameterization is clearly more popular than endpoint
parameterization. I also prefer it since I dislike APIs that involve
lots of boolean flags.
Postscript uses my preferred mechanism for resolving an ambiguity,
which is to provide distinct operators with distinct behavior rather
than passing a flag. However, I do prefer more descriptive names.
--
Carl Worth
USC Information Sciences Institute [EMAIL PROTECTED]
_______________________________________________
Render mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/render
