Bug ID: JDK-8092682 Need to re-evaluate the BND constants set in the Pisces rasterizer for non AA shapes

Type: Bug
Component: javafx
Sub-Component: graphics
Affected Version: 8u40

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2014-11-18
Updated: 2016-12-07
Resolved: 2014-11-27

JDK 8
8u40Fixed

We need to re-evaluate the BND constants, in Renderer.java, to improve the smoothness of non AA shape once RT-39424 is fixed.

Currently I have to tune the BND constants, in Renderer.java, to reduce the noisy jaggies. But it could simply an issue of RT-39424. 

BND constants changed from
    private static final float DEC_BND = 20f;
    private static final float INC_BND = 8f;

to
    private static final float DEC_BND = 5f;
    private static final float INC_BND = 2f;

We might want to revert this back once we have a more accurate center pixel sampling.
Note: Similar is also made in the native Renderer.h for native Pisces implementation.

I also note that the Canvas version of the GUIMark2 VectorChartingTest benchmark takes a performance hit of about 5-10% (comparing the original numbers before the fix for RT-39468 to the current numbers after the fix for RT-39439) depending on platform.
10-12-2014
Fixed in the 8u-dev repo with the following changeset: changeset: 8442:c864b62fb55a date: Wed Nov 26 16:11:19 2014 -0800 summary: Fix RT-39439: Re-evaluate BND constants in the Pisces rasterizer for non-AA shapes http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c864b62fb55a
27-11-2014
Nice work. Approved. +1
26-11-2014
Changing the constants to 1.0 for DEC and 0.4 for INC makes a dramatic difference in the output, improving cubic errors using the TestNonAA test from 99% failures and over 6 failed pixels per curve to around 50% warnings and only about .15 failed pixels per bad curve (meaning about a 7% paths that have 1 bad pixel). This is comparable or better than the results we get from testing the rasterizer that Java2D has been using for several years. webrev: http://cr.openjdk.java.net/~flar/RT-39439/webrev.00/ The benchmarks show some hit, but the improved rendering requires us to take this hit (the errors were really bad in many cases with the prior constants that Chien used as a stop-gap, and the errors with the original constants before Chiens fix could be seen from across the room... ;) NOTE: This is testing of the raw Rasterizer.getMask() method, this does not include the overhead to upload the results to the card and render the pixels (or render them in software for the sw pipeline). It also doesn't take into account that we cache the alpha masks for all complex shapes by default so these numbers are really only interesting to startup performance in most cases and they represent just a tiny portion of the overall work being done. Still, I thought it was important to see what the performance impact was so that we didn't just adjust the constants into ridiculously high levels of quality vs. performance. These results show significantly better performance for the final constant choices, so measure that against the performance impact you see here, and against the fact that this is only one stage of the process... Here were the results of a benchmark using the original constants (20.0/8.0, with horrible non-AA results). 1414493 10x10 Ellipse native non-AA rasterizations took 5520.02ms, 256247.8034499875 ops/sec 146433 100x100 Ellipse native non-AA rasterizations took 5056.54ms, 28959.13015619376 ops/sec 142469 100x100 Cubics native non-AA rasterizations took 6057.89ms, 23517.924557890616 ops/sec 636143 10x10 Ellipse native AA rasterizations took 2483.68ms, 256129.21149262387 ops/sec 72799 100x100 Ellipse native AA rasterizations took 2546.9ms, 28583.37586870313 ops/sec 58772 100x100 Cubics native AA rasterizations took 2496.93ms, 23537.704300881484 ops/sec And with Chien's stop-gap constants (5.0/2.0 gave bad results, but looked reasonable from arm's length with well-behaved curves): 1310115 10x10 Ellipse native non-AA rasterizations took 5474.5ms, 239312.26596036166 ops/sec (-7%) 145663 100x100 Ellipse native non-AA rasterizations took 5227.18ms, 27866.459544151912 ops/sec (-4%) 126143 100x100 Cubics native non-AA rasterizations took 6423.24ms, 19638.531333096693 ops/sec (-16%) 594465 10x10 Ellipse native AA rasterizations took 2486.14ms, 239111.63490390728 ops/sec (-7%) 69452 100x100 Ellipse native AA rasterizations took 2495.84ms, 27827.10430155779 ops/sec (-3%) 49093 100x100 Cubics native AA rasterizations took 2505.19ms, 19596.51762940136 ops/sec (-17%) And with the constants that I found gave fairly good results (1.0/0.4 as per the webrev above): 1043884 10x10 Ellipse native non-AA rasterizations took 5399.37ms, 193334.40753273066 ops/sec (-25%) 135916 100x100 Ellipse native non-AA rasterizations took 5819.39ms, 23355.7125403178 ops/sec (-20%) 104370 100x100 Cubics native non-AA rasterizations took 7108.51ms, 14682.401797282411 ops/sec (-38%) 476319 10x10 Ellipse native AA rasterizations took 2453.27ms, 194156.77850379288 ops/sec (-24%) 58281 100x100 Ellipse native AA rasterizations took 2516.71ms, 23157.614504650912 ops/sec (-19%) 36679 100x100 Cubics native AA rasterizations took 2508.96ms, 14619.204770103946 ops/sec (-38%)
26-11-2014
Attaching the RasterPerf benchmark to benchmark the output of the raw rasterizer methods outside the context of the JavaFX pipelines...
26-11-2014
Attaching the most recent TestNonAARasterization test case used to test the results of this patch and compare it to the Java2D rasterizer.
26-11-2014

Blocks :	JDK-8094493 - Need a more accurate center of pixel sampling for supporting 1 sample per pixel rendering
Relates :	JDK-8170879 - Fix Quad / Cubic BND constants for Marlin (FX)