Before we come to any conclusions on performance, though, we might want to run this on something like a Microsoft
Surface that uses a mobile processor (m3 in the low end) that might not perform as well with doubles. Does anyone have
a low-end Surface they could try these patches on and see how they affect performance?
...jim
On 11/30/16 2:12 PM, Laurent Bourgès wrote:
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.
