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

Denis Lila dlila at redhat.com
Fri Dec 10 16:27:45 UTC 2010


Hi Jim.

> By "without this optimization" do you mean back when you did a full
> scan for the proper T?

Yes. The improvement shown by the bench marks is substantial.

> Then this is great news!

Indeed :-)

> How often do we end up needing getTCloseTo in practice?

It depends on the ratios of the lengths of the sides of the control
polygon. The closer they are to 1, the less we need it. I'm not sure
how to answer more precisely - for that I would need a representative
sample of curves drawn in practice.

However, I did run dashing and stroking benchmarks. Stroking shows
25% speedup (because of the refinements to the transform pipeline)
and cubic dashing has improved by 80%. Of course, all this is useless
if I've done something to make things look horrible, so I'm going to
run the gfx tests again.

Regards,
Denis.

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

> 
> 			...jim
> 
> On 12/8/2010 1:54 PM, Denis Lila wrote:
> > Hi Jim.
> >
> >>> How about "if the 3 segments of the control polygon are all close
> to
> >>> each other in length and angle", then the optimization applies. 
> Is
> >>> that easy to test?
> >>
> >> Hmm, that would actually be extremely easy to test and it would
> cost
> >> almost nothing. We already compute the control polygon lengths in
> onLeaf, and
> >> we're already assuming that every leaf is "flat enough", so we
> >> probably don't even need to check the angles. Comparing lengths
> should be good
> >> enough.
> >> I'll try this out.
> >
> > I implemented this and updated the webrev. I tested on a few curves
> with very high
> > and very low accelerations. The results were identical to what I
> used to get
> > without this optimization. When the curve has no acceleration, all
> calls of getTCloseTo
> > are skipped.
> >
> > Regards,
> > Denis.



More information about the 2d-dev mailing list