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" <m...@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 >
