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

[Jim Graham]

Hi Denis,

The example I gave was intended to be very crude - I was simply 
describing the technique, but as I said it would require better math to 
really know what the right formula would be.

With respect to finding a cubic root, currently you are doing that in 2 
dimensions, but what if we converted to 1 dimension?

Consider that the control polygon is "fairly linear".  What if we 
rotated our perspective so that it was horizontal and then squashed it 
flat?  Consider instead a 1 dimensional bezier with control values of:

(where |mn| is the length of the m->n control polygon of the original 
curve - sum of all segments from point m to point n)

0.0, |01|, |02|, |03|

Solve that 1 dimensional bezier for v=(leaflen*polylen)/linelen...

			...jim

On 12/10/2010 8:23 AM, Denis Lila wrote:
> 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.