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

Denis Lila dlila at redhat.com
Wed Aug 25 21:36:47 UTC 2010

```Hello Jim.

> I think a more dynamic approach that looked at how "regular" the curve
> was would do better.  Regular is hard to define, but for instance a
> bezier section of a circle could have parallel curves computed very
> easily without having to flatten or subdivide further.  Curves with
> inflections probably require subdividing to get an accurate parallel
> curve.

I'm not sure if you read it, but after the email with the webrev link
I sent another describing a different method of widening: split the
curve at every t where dx/dt == 0 and dy/dt == 0. This guarantees that
there will be no more than 5 curves per side, and since each curve will
be monotonic in both x and y the curve that interpolates its parallel
should do a pretty good job.

This is far better than interpolating at regular t intervals, but I'm
trying to find a better way. I don't like this because the split
depend not only on the curve itself, but also on the axes. The axes are
arbitrary, so this is not good. For example a curve like this
|
\_ would get widened by 1 curve per side (which is good and optimal), but
if we rotate this curve by, say, 30 degrees it would be widened by 2 curves
per side.
It also doesn't handle cusps and locations of high curvature very well (although
I think the latter is a numerical issue that could be made better by using
doubles).

Regards,
Denis.

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

> Hi Denis,
>
> On 8/23/2010 4:18 PM, Denis Lila wrote:
> >      To widen cubic curves, I use a cubic spline with a fixed number
> of curves for
> > each curve to be widened. This was meant to be temporary, until I
> could find a
> > better algorithm for determining the number of curves in the spline,
> but I
> > discovered today that that won't do it.
> >      For example, the curve p.moveTo(0,0),p.curveTo(84.0, 62.0,
> 32.0, 34.0, 28.0, 5.0)
> > looks bad all the way up to ~200 curves. Obviously, this is
> unacceptable.
> >
> > It would be great if anyone has any better ideas for how to go about
> this.
> > To me it seems like the problem is that in the webrev I chop up the
> curve to be
> > interpolated at equal intervals of the parameter.

>
> Perhaps looking at the rate of change of the slope (2nd and/or 3rd
> derivatives) would help to figure out when a given section of curve
> can
> be approximated with a parallel version?
>
> I believe that the BasicStroke class of Apache Harmony returns widened
>
> curves, but when I tested it it produced a lot more curves than Ductus
>
> (still, probably a lot less than the lines that would be produced by
> flattening) and it had some numerical problems.  In the end I decided
> to
> leave our Ductus stuff in there until someone could come up with a
> more
> reliable Open Source replacement, but hopefully that code is close
> enough to be massaged into working order.
>
> You can search the internet for "parallel curves" and find lots of
> literature on the subject.  I briefly looked through the web sites,
> but
> didn't have enough time to remember enough calculus and trigonometry
> to
> garner a solution out of it all with the time that I had.  Maybe
> you'll
> have better luck following the algorithms... ;-)
>
> As far as flattening at the lowest level when doing scanline
> conversion,
> I like the idea of using forward differencing as it can create an
> algorithm that doesn't require all of the intermediate storage that a
>
> subdividing flattener requires.  One reference that describes the
> technique is on Dr. Dobbs site, though I imagine there are many
> others:
>
> http://www.drdobbs.com/184403417;jsessionid=O5N5MDJRDMIKHQE1GHOSKH4ATMY32JVN
>
> You can also look at the code in
> src/share/native/sun/java2d/pipe/ProcessPath.c for some examples of
> forward differencing in use (and that code also has similar techniques
>
> to what you did to first chop the path into vertical pieces).  BUT
> (*Nota Bene*), I must warn you that the geometry of the path is
> somewhat
> perturbed in that code since it tries to combine "path normalization"
>
> and rasterization into a single process.  It's not rendering pure
> geometry, it is rendering tweaked geometry which tries to make non-AA
>
> circles look round and other such aesthetics-targeted impurities.
> While
> the code does have good examples of how to set up and evaluate forward
>
> differencing equations, don't copy too many of the details or you
> might
> end up copying some of the tweaks and the results will look strange
> under AA.  The Dr. Dobbs article should be your numerical reference
> and
> that reference code a practical, but incompatible, example...
>
> 			...jim

```