Follow-on bugs

[Laurent Bourgès]

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.laurent at 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.
>>
>