JDK-8096840 : Dirty region problems with blurs with large radii
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-25
  • Updated: 2015-06-12
  • Resolved: 2014-06-05
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
8u20Fixed
Related Reports
Relates :  
JDK-8093185 - GaussianBlur always renders at 1:1 scale and may be unnecessarily blurry in a scaled scene
Description
While fixing RT-13275 I noticed some dirty region problems with some of its test cases.  This could be a disagreement between the bounds calculated at the FX layer and the NG/Decora layer, but I didn't track it too far other than to note that the implementations between those two layers differ in their calculations of the fringe of affected pixels in blurs and shadows.

To reproduce:

1. Run the BlurTest.java example.
2. Check the "blue bg" checkbox for improved visibility.
3. Slide the blur sliders all the way to the right for maximum blur.
4. Play with the "mb angle" slider to adjust the angle of the Motion Blur.
5. As you slide the mb angle slider back and forth notice issues with the clearing/damage repair of its bounds.
6. Run the example with dirty opts off and notice that there are no rendering anomalies.

7. Do the same thing with the ShadowTest.java example.
8. (There is no "blue bg" checkbox, shadows are fairly visible by default.)
9. Max the blur sliders and play with the "ds spread" slider to see the damage repair issues.
Comments
http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e2d745ffbf0a
06-06-2014
Fixed in the 8u-dev repository with the following changeset: changeset: 7200:e2d745ffbf0a date: Thu Jun 05 16:22:09 2014 -0700 summary: Fix RT-36016: Dirty region (actually clipping) problems on blurs with large radii Tested with the test cases attached to the linked report as indicated in the description.
05-06-2014
Looks good. Approved.
05-06-2014
Fix: http://cr.openjdk.java.net/~flar/RT-36016/webrev.00/ The inputSizeHV that were being used were independent of the number of passes and so only padded enough for blurPasses=1. getInputKernelSize's job is to pad by the inputSizeHV, iterated over the appropriate number of passes.
05-06-2014
Ah, if I had looked more closely I might have noticed that the other blurs aren't being completely ignored (which would make sense if they were failing a dirty opt test), but they were just "more faint" than they should be. The real culprit is not the line above which is correct, it is that when the filterClip is padded to bring in extra data around the sides that will contribute to the blurred output, not enough extra data was being requested by the Box Shadow implementation.
05-06-2014
I'll check what's going on there...
04-06-2014
Dirty regions are correct, the problem is in handling of the dirty region in effect processing. The 2 boxes below the "Drop" button convert the correct dirty region clip to an empty clip although their bounds intersect with the dirty region. The following line in FilterEffect(:180) results in a bad clip for effect filter: filterClip = untransformClip(resulttx, outputClip); The outputClip is the correct clip of the Scene, so it must be resulttx or untransformClip method that's wrong.
04-06-2014
This bug does not happen in FX 8, so it appears to be a regression (although it may be that we just exposed a bug that was there all along).
03-06-2014
Attached a screenshot of the problem (Shadow-Bad) and a screenshot with "-Dprism.dirtyopts=false" (Shadow-Good).
03-06-2014