Follow-on bugs

Laurent Bourgès bourges.laurent at
Wed Nov 30 22:12:22 UTC 2016


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:
- raw that makes no comparison to be easily applicable as a patch:

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

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


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.

More information about the openjfx-dev mailing list