Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8170030

Code in Marlin-based rasterizers may have an off-by-1 bug (causing extra work, no failures)


    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: javafx
    • Labels:


      The following code appears in the 3 versions of the Marlin rasterizer endRendering() method (Marlin2D, MarlinFX_AA, MarlinFX_NoAA):

      1310 // bounds as inclusive intervals
      1311 final int spminX = FloatMath.max(FloatMath.ceil_int(edgeMinX - 0.5f), boundsMinX);
      1312 final int spmaxX = FloatMath.min(FloatMath.ceil_int(edgeMaxX - 0.5f), boundsMaxX - 1);

      The spminX uses inclusive values for both the edgeMinX and boundsMinX values, but the spmaxX uses a mixture of inclusive/exclusive values. "ceil(x-0.5)" on a right edge is an exclusive value (that coordinate is not rendered), but boundsMaxX-1 is an inclusive value.

      I don't think this leads to a bug since we clip against the "inclusive edge" of the clip box so we never process beyond the addressable pixels in the destination, but it may lead to processing one additional provably-0-coverage sample for each row since the edgeMaxX value represents the last recorded edge sample.

      If this is indeed an issue (causing us to process an extra column), then a similar fix would be needed in 2 files in the MarlinFX code and 1 file in the Marlin2D code - a separate related bug would need to be filed against Marlin2D since they are in separate projects.


          Issue Links



              • Assignee:
                lbourges Laurent Bourg├Ęs
                flar Jim Graham
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: