Follow-on bugs

[Jim Graham]

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