Follow-on bugs

[Laurent Bourgès]

Hi,

For large curves, I would recommend using a first step to subdivide the
curve into smaller ones (1024 pixels as described in Lien paper) to ensure
the AFD algorithm preserves enough accuracy with float values (first) in
the Dasher.

Basic recursive subdivision at halves with a large flatness tolerance would
do the job... this initial step could also subdivide at cups, inflexion and
roots for fills ?

Moreover, it could help a basic clipper based on simple hulls (all control
points) to reject curve portions out of the top, bottom and maybe right and
left parts (tricky as interior rules are based on left to right
intersections...)

What are good curve length estimators ?

Help is welcome as usual and will have a look to the test classes asap.

PS: anyway I will later try using doubles instead of floats in Marlin, but
it will time consuming, so let's postpone such task.

Cheers,
Laurent

Le 29 nov. 2016 08:37, "Michael Paus" <mp at jugs.org> a écrit :
>
> Am 29.11.16 um 01:09 schrieb Jim Graham:
>
>>
>> With respect to float/double, I have another bug somewhere where we have
a large inaccuracy for a very large circle that intersects the viewing area
along only a very tiny portion.  The errors get especially bad with dashing
because we iterate each dash using an incrementally relative sub-divide
rather than returning always to the original curve to sub-divide from
t1-to-t2.  I'll look it up and send you a pointer so you can see how Marlin
does with those paths.  I believe that I briefly modified the Pisces Dasher
to simply use doubles and the problem went away, but I didn't do any
performance analysis and the newly accurate dashes no longer matched the
still-float-based fills so more work was needed. Modern processors tend to
deal with double precision natively and so other than storage
considerations double calculations are often as fast or sometimes faster
than float (because of not needing to be cast back to 32-bit float when the
FPU always produces 64-bit double answers)...
>
> I can help you out here because I have reported these bugs. The
references are
>
>  https://bugs.openjdk.java.net/browse/JDK-8160599
>  https://bugs.openjdk.java.net/browse/JDK-8160600
>
> I also think that using doubles instead of floats would make things much
more accurate
> especially as the user actually can expect that because the JavaFX API
also uses doubles
> and it is not clear to the user that this is currently reduced internally
to float.
>
> Michael
>