[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces

[Jim Graham]

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