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