Hi Denis,
On 11/8/2010 2:39 PM, Denis Lila wrote:
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.
All lines generated from a given "allegedly monotonic" curve are
recorded with the same "or" (orientation) value. But, if the curves are
not truly monotonic then it might be theoretically possible to generate
a line that is backwards with respect to the expected orientation. It
would then get recorded in the edges array with the wrong orientation
and slope and then rasterization might unravel.
Fortunately, the non-monotonicity is limited to a few bits of precision
so this may never generate an errant edge in practice unless flattening
gets really fine-grained...
...jim
