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

[Denis Lila]

Hi Jim.

> 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?

That's because I used to have only one AFD function that worked for both
cubics and quadratics. It simply treated quadratics as cubics with the
first coefficient 0. I decided to split them up because we might want
to do different things for quadratics, but I didn't get around to doing
any of them (yet) so that's why it is the way it is.

> 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.

Well, making them monotonic makes updating edgeM[in|ax][X|Y] more efficient.
We only have to do the tests once per subdivided curve instead of once per
line. Also it helps with making our lines have y2>y1. Without monotonicity
we'd have to test each individual line, instead of just reversing the 
curve coordinate array. However, for the latter, all we need is monotonicity
in Y. We should make some measurements to determine whether the above
are enough to compensate for the subdivision costs.

> 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...

Making curves monotonic is only used for optimization purposes,
so it can't see how it would affect rendering correctness.

Regards,
Denis.

----- "Jim Graham" <james.graham at oracle.com> wrote:

> 
> 				...jim