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

[Jim Graham]

Hi Denis,

On 12/7/2010 10:47 AM, Denis Lila wrote:
> Hi Jim.
>
>> I'm sure you will likely find a root, but the method you are using is
>> "roots*inAB*" which may throw the root out because it is out of range,
>> no?
>
> I'm sure some roots will be thrown out, but I think in every call of
> getTCloseTo there will be at least one root that isn't thrown out. That's
> because our [A,B) is always [0, 1), and the point x,y that we pass
> to getTCloseTo lies on the line joining the endpoints of the curve on
> which getTCloseTo is called, so there must be some root in [0, 1). In fact,
> there will be two roots, one for each parametric polynomial.

The main problem is that "must" doesn't exist for IEEE floating point 
numbers.  You can find the root for one of the endpoints and it may 
return "t = -.00001" even though the value exactly matched the endpoint, 
but after all the math was said and done the answer it came up had the 
bit pattern for a tiny negative number, not 0 (or 1.0001).  That t value 
would be rejected and then you'd have no roots.

> I implemented your way. I couldn't get rid of outat, however. In that case
> where we have to apply a non orthogonal transform with no normalization we
> want to just apply the transform at the end of stroking and feed stroker
> untransformed paths. So, now I have both outat and strokerat. At least
> one of them must always be null. In the case I mention above, strokerat will
> be null, and the calls to *deltaTransformConsumer(pc2d, strokerat) won't
> do anything, but the transformConsumer(pc2d, outat) call will take care of
> the post stroker transformation.

Oh, I see, we have 3 possible chains:

    PI => AT => stroke => render
    PI => AT => normalize => 1/at => stroke => at => render
    PI => normalize => stroke => AT => render

So sometimes the final transform needs to be full and sometimes it needs 
to be delta.  It looks like it works.

> I don't think the TranslateFilter will ever be used, because transformConsumer
> is now called only with outat, which cannot be a translation. So we may want
> to remove it.

It's not hurting anything and we may find it useful in other contexts. 
We probably should have put it in a more generic package.

> I also fixed the filterOutNotInAB function. It was violating cubicRootsInAB's
> spec by filtering out everything not in (A, B), as opposed to everything not
> in [A, B), which is what it should do.

Shouldn't it be [A, B]?

New stuff:

Curve.java:

getMaxAcc functions - don't we want the furthest value from 0, positive 
or negative?  You are looking for most positive value and negative 
accelerations are equally problematic, aren't they?  If so then these 
functions need some work.

lines 118,141 - aren't these always true?  Should this be "&&"?

I also still need to look at the new Renderer stuff...

				...jim