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

[Jim Graham]

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