Jim, I found the bug in RendererNoAA caused by a 'bad' regexp match: 0x7fffffff was modified to 0x7Dffffff !
so there is no more regression in TestNonAARasterization ! Laurent FYI, here is the diff of the correction (over the previous big patches): < +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java 2016-11-30 22:48:51.710420442 +0100 --- > +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRenderer.java 2016-11-30 23:35:42.879588649 +0100 2276,2277c2276,2277 < + private static final int ALL_BUT_LSB = 0xfffffffe; < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 --- > + private static final int ALL_BUT_LSB = 0xFFFFFFFe; > + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 2675,2676c2675,2676 < + // = fixed_floor(x1_fixed + 0x7Dffffff) < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) --- > + // = fixed_floor(x1_fixed + 0x7FFFFFFF) > + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) 2681c2681 < + + 0x7DffffffL; --- > + + 0x7FFFFFFFL; < +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java 2016-11-30 22:48:52.662420517 +0100 --- > +++ new/modules/javafx.graphics/src/main/java/com/sun/marlin/DRendererNoAA.java 2016-11-30 23:35:43.835587936 +0100 4147,4148c4147,4148 < + private static final int ALL_BUT_LSB = 0xfffffffe; < + private static final int ERR_STEP_MAX = 0x7Dffffff; // = 2^31 - 1 --- > + private static final int ALL_BUT_LSB = 0xFFFFFFFe; > + private static final int ERR_STEP_MAX = 0x7FFFFFFF; // = 2^31 - 1 4537,4538c4537,4538 < + // = fixed_floor(x1_fixed + 0x7Dffffff) < + // and error = fixed_fract(x1_fixed + 0x7Dffffff) --- > + // = fixed_floor(x1_fixed + 0x7FFFFFFF) > + // and error = fixed_fract(x1_fixed + 0x7FFFFFFF) 4543c4543 < + + 0x7DffffffL; --- > + + 0x7FFFFFFFL; 2016-11-30 23:12 GMT+01:00 Laurent Bourgès <bourges.laur...@gmail.com>: > Jim, > > As announced yesterday night, I made a new 'Double' (alias D) pipeline for > marlinFX with 2 webrevs: > - cmp that compares the D pipeline vs the float pipeline: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-cmp/ > - raw that makes no comparison to be easily applicable as a patch: > http://cr.openjdk.java.net/~lbourges/marlinFX-D/marlinFX-Double-raw/ > > As explained, I duplicated the complete pipeline (including > MarlinRasterizer) so both can be used for comparisons. > To enable the D pipeline, just add -Dprism.marlin.double=true else the > float pipeline will be used ! > > I left the conv.sh script that makes the 90% of the class conversions. > > > It is very preliminary as I doubt we will keep two pipelines (for > maintenance reasons) and here my test results: > - DemoFX (stars / sierpinski) / GuiMark performance are so close that I > can not really see any real difference on my linux with intel 7-4800 ; > maybe other cpu may have more impact with double vs float but the > floating-point computations are representing a minor part of the shape > rendering (dasher, stroker, curve interpolation in Renderer) > > Quality: > - Dasher issue with large shapes: all issues are fixed with marlinFX-D > (rect, circle) > - TestNonAARasterization: the errors seem are more important (poly, quad, > cubic) so there may be either a bug in the test (Path2D comparisons) or an > important issue in the D pipeline as also polygons are affected > > I wanted to present you this work to get your early feedback and mention > the issues with TestNonAARasterization that will require some work to > understand clearly what's happening ! > > Cheers, > Laurent > > As I wanted to use double precision for long, I ported main marlinFX >> classes using a tricky sed scripts... fixed the 'D' pipeline and it seems >> already working well. >> >> The 2 mentioned bugs are then fixed + the performance ob DemoFX / GUIMark >> (webview) seems the same as the hot spot is in scanline processing + >> coverage / mask processing, not in the dasher or stroker parts. >> >> This first prototype is promising and it only took me few hours... >> >> However, subdiving large curves is still an interesting option to >> preserve quality / accuracy even with double precision as mentioned in my >> previous email. >> >
