[OpenJDK 2D-Dev] X11 uniform scaled wide lines and dashed lines; STROKE_CONTROL in Pisces
james.graham at oracle.com
Wed Dec 8 00:57:23 PST 2010
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,
> 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]?
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...
More information about the 2d-dev