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

[Jim Graham]

Hi Denis,

At the bottom-most rendering level monotonic curves can be cool to deal 
with, but I'm dubious that they help with widening.  For one things, I 
think you need more breaks than they would give you and also they might 
sometimes break a curve when it doesn't need it.


One way in which they may not break enough is that I think that 
inflections also need to be broken in order to find a parallel curve 
(though I suppose a very tiny inflection might still be approximated by 
a parallel curve easily) and inflections can happen at any angle without 
going horizontal or vertical.


Secondly, although a circle tends to be represented by quadrant sections 
which are monotonic, a circle rotated by 45 degrees would have 
horizontal and vertical sections in the middle of each quadrant and you 
would split those, but really they can be made parallel regardless of 
angle so these would be unnecessary splits.


My belief is that lengths and angles of the control polygon help 
determine if it is well-behaved and can be made parallel simply by 
offsetting.  Some formula involving those values would likely be happy 
with circle sections regardless of their angle of rotation.  I believe 
the Apache Harmony version of BasicStroke used those criteria...


...jim

On 8/25/2010 2:36 PM, Denis Lila wrote:

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"  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 h

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

[Denis Lila]

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

Re: [OpenJDK 2D-Dev] Concurrent execution of SunLayoutEngine.getEngine(..) may cause corrupt HashMap

[Dalibor Topic]

On 8/23/10 5:48 PM, Thorsten Jungblut wrote:

> I created a patch (using latest OpenJDK7 sources from mercurial):

Hi Thorsten,

I couldn't find your name on the SCA signatories list. 
Please see http://openjdk.java.net/contribute/, 
in particular step 0.

In order to avoid having your patch get lost in mail meanwhile, 
please file it in the OpenJDK bugzilla at bugs.openjdk.java.net.
Thanks!

cheers,
dalibor topic
-- 
Oracle 
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738  | | | Mobile: +491772664192 

Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle  Oracle is committed to 
developing practices and products that help protect the environment