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
