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

[Denis Lila]

Hi Jim.

> Actually, even if the lengths aren't close the lengths may give you 
> enough information about the acceleration along the curve that you can
> do a decent approximation of the accelerated T value.  The T could be
> biased by some formula that is weighted by the ratios of the control 
> polygon lengths.  As a very crude example, say you assumed that if the
> scaled leaf length fell into the first polygon segment's length then t
> should be proportionally a value from 0 to 1/3, and if it fell between
> the first poly len and the second then it would be proportionally a 
> value from 1/3 to 2/3, etc.  The code might look like this:

I implemented this, and I'm not sure how to use this new approximation.
I mean, currently there are really two t's. The first one is the parameter
along the line connecting the 2 endpoints of the curve and the second
is the result that we return. We can't use this new approximation to
replace the first t, because for a curve like
(0,0),(1000,0),(1000,0),(1000,0) and a desired length of 500, the t
would be 1/6, so the computed (x,y) would be (1000/6,0) instead of
(500,0), which would be right (and which is what we compute now).

The only sensible way to use this kind of approximation would be as a
direct replacement for getTCloseTo. I tried that, and its quality to
speed ratio compared to getTCloseTo is remarkably good, but it's not
really usable because the differences are very noticeable.
I'll try to implement a good cubic root finder this weekend, and maybe
then getTCloseTo will be much faster and we won't have to worry about
this.

> (Also, note that in the original code we probably would have just been
> dashing along the flattened curve anyway and so we might have just
> been 
> using the raw linear t in that case - so anything we do here is a 
> refinement of what we used to do and "icing on the cake" to some
> extent)...

I'd say the dashing precision is better than what we used to have. It's
only slightly better, but even that is impressive when you consider that
we were doing up to 1024 subdivisions before, and now it's only 16, I think.

Regards,
Denis.