Follow-on bugs

[Jim Graham]

If this eliminates the regressions in TestNonAA, then I'm for reworking this as an in-place patch for MarlinFX.

We can't use the existing Dasher bug for this because Marlin isn't the default renderer, but we can mention the 
DMarlinFX bug as a workaround for the Dasher bug...

			...jim

On 11/30/16 2:41 PM, Laurent Bourgès wrote:
> 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.
>>>
>>