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

[Jim Graham]

Hi Denis,

Yes, I remember this now that you reminded me.  I'm sorry for having let 
it slide the first time... :-(

Curve.java:

line 134 - what if numx or numy == 0 because only roots outside [0,1] 
were found?

line 145 - what if d0 and d1 are both 0?  NaN results.  What if you just 
used a simple "d0 < d1 ? tx : ty" - how far off would that be?

line 152,154 - you are likely picking the most negative distance here, 
not the closest to zero.  abs() might help.

line 187 - is that correct?  Shouldn't it be "(...) + 0.5*(...)"?
          - if that is true then perhaps the change in scale didn't
            really reduce the number of multiplies?

Dasher.java:

line 220 - any reason to move this method?

line 238 - ah, perhaps the lion's share of the performance improvement?

line 357 - another optimization would be to check the acceleration in 
the range and if it is below a threshold then simply use the t from line 
348 as the t for the split

line 378 - comment applies to deleted function
          - also, maybe move bsc declaration up closer to next() method?

Helpers.java:

line 83 - conflicts with test at line 89

Renderer.java:  Is this just a straight copy of what I was working on? 
I hate to be a whiner, but I'd rather avoid having to go over every line 
and check it... ;-)

TransformingPathConsumer2D:

Any thoughts on whether we need translation in the scale filter and 
whether a 4-element non-translation filter would be useful?  I think the 
current code that drives this passes in the full transform and its 
inverse, but it could just as easily do delta transforms instead and 
save the adding of the translation components...

		...jim

On 12/1/2010 9:19 AM, Denis Lila wrote:
> Hi Jim.
>
> About two weeks or so ago I replied to one of your very old e-mails
> about dashing performance and I included a link to the webrev:
> http://icedtea.classpath.org/~dlila/webrevs/perfWebrev/webrev/
>
> I suspect you might have missed it, so that's why I'm writing this.
> If you haven't, I apologize for this e-mail.
> Anyway, here's the e-mail:
> http://mail.openjdk.java.net/pipermail/2d-dev/2010-November/001654.html
>
> I also just found a bug in the cubic roots math: in the case where the function
> was quadratic, I was forgetting to filter the computed roots to include
> only ones in the range [A, B).
>
> Regards,
> Denis.
>
> ----- "Jim Graham"<james.graham at oracle.com>  wrote: