[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
james.graham at oracle.com
Fri Dec 10 23:15:08 UTC 2010
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...
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
>> (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
>> 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
> 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.
More information about the 2d-dev