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