A couple of questions about the code that I haven't touched...
Is there some reason why the AFD for cubics doesn't have any tests for
dddxy (the "constants" for its equations), but the AFD for quads is
testing the ddxy on every loop? I know that these values do change when
the AFD variables are doubled or halved, but why does the cubic version
get away with only testing out to the n-1th order differences but the
quad version has to test out to the nth order differences?
Also, what is the value of breaking the pieces into monotonic segments
prior to flattening? Is it simply amortizing the cost of determining if
the segment is up or down? I guess this used to be done because we
needed monotonic (in Y) curve segments since we did a top-down iteration
across all segments, but now they aren't in the rasterization loop. If
it is simply a performance issue then I may experiment with eliminating
that stage and seeing if I can make it go faster overall.
Finally, I discovered (while testing for other problems) that the curves
are not truly monotonic after slicing them. I realized this years ago
when I was writing my Area code (see sun.awt.geom.Curve) and put in
tweaking code to make them monotonic after they were split. They are
never off by more than a few bits, but you can't trust the curve
splitting math to generate purely monotonic segments based on a t
generated by some unrelated math. Sometimes the truly horizontal or
vertical t value requires more precision than a float (or even a double)
can provide and splitting at the highest representable float less than
the t value produces a pair of curves on one side of the hill and
splitting at the next float value (which is greater than the true t
value) produces curves on the other side of the hill. Also, when the
curve has been split a few times already, the t values loose accuracy
with each split. This will all be moot if I can eliminate the splitting
code from the renderer, but it may also play a factor in the stroke/dash
code...
...jim
