JDK-8094493 : Need a more accurate center of pixel sampling for supporting 1 sample per pixel rendering
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-11-18
  • Updated: 2016-11-19
  • Resolved: 2014-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8u40Fixed
Related Reports
Blocks :  
JDK-8088013 - Bleeding Edges - Background Bleeding on Shared Edges for 3D Multi-Polygon Configurations
Blocks :  
JDK-8094313 - Overlapping 3D transformed 2D shapes have dirty edges in Scene with depth buffer
Blocks :  
JDK-8092682 - Need to re-evaluate the BND constants set in the Pisces rasterizer for non AA shapes
Relates :  
JDK-8095471 - [TableView] TableCell border lines are rendered incorrectly
Relates :  
JDK-8169270 - Leverage new Java2D Marlin rasterizer for JavaFX
Description
This is a follow-on work for RT-38063. We noticed that the 1 sample sampling isn't quite a the center of pixel. Jim checked and believed this is certainly caused by sloppy sampling locations which isn't a problem for AA fuzziness (center of 8xsub-pixel sample is less likely to produce visual artifacts than center of single-pixel samples).
Comments
Fixed in the 8u-dev repo with the following changeset: changeset: 8424:d094365ab0c5 date: Sun Nov 23 21:19:59 2014 -0800 summary: Fix RT-39424: non-AA rendering should sample at centers of pixels http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d094365ab0c5
24-11-2014
+1 I also noticed there is a good reduction of cracks on BleedingEdges.jar (see RT-38063).
22-11-2014
Looks good. +1
22-11-2014
This fix should fix all of the registration errors (representing sampling in the center of pixels) and indeed it passes the test case for all non-curved shapes (rect, octagon, poly, bigpoly). Running the fix with curves shows minimal improvement. Using "-oval" it improves from 98.5% bad paths to 96.7% bad, and the number of errors per bad path from an average of 37.5 bad pixels to 7.5 bad pixels. More work will be needed on RT-39439 (reevaluate subdivision constants for curves) before we improve the curves, but the issue of where in the pixel we are sampling should be completely fixed by this change. webrev: http://cr.openjdk.java.net/~flar/RT-39424/webrev.00/ Tested on: test case with -rect, -octagon, -poly Mac es2, Mac sw native and software pisces
22-11-2014
Attaching a test case that verifies the rasterization of non-AA shapes against their contains() methods (with appropriate center-of-pixel registration). It takes a parameter that defines the kind of shape to use: -rect simple rectangles -oval simple ellipses -octagon octagons -poly 5-sided polygons -bigpoly 9-sided polygons -cubic pairs of cubic curves -quad sets of 4 quadratic curves It shows paths that have errors (or warnings) and red/green crosshairs where the pixels were correctly rendered. Hopefully it doesn't show any results meaning a "perfect run", but curves may never be 100% perfect. It also keeps statistics on the number of paths with warnings or errors and the average number of warnings or errors per bad path.
22-11-2014
I was hoping having an accurate center of pixel sampling might be good enough. I have filed a separate BND constants re-evaluation JIRA (RT-39439) to look into it.
18-11-2014
The BND changes have nothing to do with where in the pixel we are sampling. They are completely independent issues.
18-11-2014