Hi,
could someone please take a look at bug #100150?
https://bugs.openjdk.java.net/show_bug.cgi?id=100150
Thanks
Best regards
Thorsten Jungblut
Hi Jim.
> The problem is that pruning complicates the inner loop that advances
> the scanline and you can't tell without scanning every segment in play
> whether you need to do it in its own loop. Thus, for one of my test
> cases it was really expensive without some up front record of whether
>
Hi Jim.
> All lines generated from a given "allegedly monotonic" curve are
> recorded with the same "or" (orientation) value. But, if the curves
> are not truly monotonic then it might be theoretically possible to
> generate a line that is backwards with respect to the expected orientation.
>
Hi again.
I just thought of this: if we're really concerned about the accuracy
of the edgeMinX edgeMaxX variables, we could find the curves'
critical points and use them to compute the min/max X values. After all,
we're creating (or rather "setting") the Curve objects anyway. This isn't
as fast a
Hi Denis,
On 11/9/2010 3:06 PM, Denis Lila wrote:
I see. In that case, I think it's a good idea if we don't make curves
"monotonic". I already did this, by moving the edgeMin/axX/Y handling
and orientation computations in addLine. This did make it slower compared
to the file you sent me, but onl
I ended up going with:
- get rid of edgeMxy in all methods but addLine()
- addLine computes min/max of first/lastScanline
- addLine also computes min/max of x1,x2 values
this turned out to be just about the same speed for my FX rendering
version (which I believe is more sensitive than the way i
