JDK-8090176 : Pisces software renderer shows incomplete border images in particular situation
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-04-15
  • Updated: 2020-01-31
  • Resolved: 2016-09-08
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 JDK 9
8u152Fixed 9Fixed
Description
I found this issue while I was working on a customer project. And I am creating this issue to get your help to solve this problem. 

As far as I examined, the Pisces S/W renderer has a bug related to handling some properties of JavaFX CSS (Cascading Style Sheets). 

If I run 'SearchBox.jar' with ���-Dprism.order=es2��� or ���-Dprism.order=d3d���, there���s no problem. 
However, if I run it with ���-Dprism.order=sw��� option, the border image is displayed incompletely.
���SearchBox.jar��� is one of the test cases of Ensemble.jar and it belongs to the JavaFX repository.
(under \apps\ga-samples\Ensemble) 

Since this problem happens only if the software renderer is used, I suspect that the software renderer has an issue.

In detail, the problem occurs when the 'left' property for ���-fx-border-image-slice��� and ���-fx-border-image-width��� are the same. 
In the following CSS properties, '22' indicates the 'left' property. 

< SearchBox.css > 
-fx-border-image-slice: 12 12 12 22 fill; 
-fx-border-image-width: 12 12 12 22; 
(the top, right, bottom, and left) 

('javafx.runtime.version=8.0.40' version of the JavaFX was used for desktop)

I'll attach the Jar file of the tested application and screen captures related to this issue. 
( Download Url: https://drive.google.com/folderview?id=0B7VKR77zzBAySThQZlExRWxPTlk&usp=sharing )
Comments
The patch applied cleanly to 8u-dev with just a change of source paths.
30-09-2016
I think this has baked long enough in 9 to warrant a backport to 8u. This is approved to backport to 8u-dev for 8u122. If the patch applies cleanly (adjusting for the file locations) then go ahead and push it. Otherwise, please post an updated webrev matching what you pushed to 9.
30-09-2016
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/676b2591f081
08-09-2016
The .02 version looks good to me. I can confirm the testing results on my machine, too. +1
07-09-2016
I noticed a slowdown for 1:1 blits which we might encounter for things like a window whose sole content is a large canvas that is blitted on every frame. I imagine that in some cases we might also hit the same situation when copying data from one buffer to another which might happen in some cases of double buffering or transferring the results of an intermediate buffer rendering to another buffer. To avoid any such slowdowns I modified the NO_REPEAT_NO_INTERPOLATE case of the TRANSLATE case to be just about as fast as the old NO_TRANSLATE case which was a thin (but incorrectly written) veneer over memcpy. The new code has the advantage that many blits that used to only have a TRANSLATE component, but otherwise be unscaled are now copied much faster - as fast as we used to go for the rare case of a 1:1 blit. This new code is still a couple of percentage points slower than the old 1:1 code, but is now correct and much faster than the old TRANSLATE code which was used for a much larger number of blits. It won't help if the blits were to non-pixel locations, but if they are snapped to pixels (and not at the origin) then they should be faster than they used to be by a large amount. New webrev for 9, though a nearly identical webrev would apply to 8u-dev as well (after we test this in 9 for a couple of weeks): http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.02/
06-09-2016
Looks good. +1
02-09-2016
After further investigation and consideration, Kevin and I decided that the best course of action was to simply remove the "optimal" code that was not working here since it was hardly ever used (when do we ever have no translations at all in a scene graph, for instance?) and fall through to the nearly-as-optimal translation code which was responsible for 99% of our operations anyway (and so was much better tested). Here is a patch for the 9u-dev repos: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.01/ And a patch for the 8u-dev repos: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.8u.01/ We will let this bake in the 9u-dev repos for a couple of weeks before doing a backport to 8u-dev - likely to appear in the 8u122 time frame.
02-09-2016
The following patch fixes the problem and mostly make sense, except for the fact that there is no documentation on why that one single case out of all of the cases in that method refers to rectX/Y and does not refer to currX/Y like the others. I'm guessing it only really gets used from the drawImage case (other cases would probably be an ImagePattern which would be handled by the "if (repeat)" code blocks. http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.00/
05-11-2015
It happens only when the render scale is 100% so we may see less of this in 8u60 with Windows HiDPI, but it will still happen on 100% and 125% screens.
24-07-2015
We may want to backport this to 8u60 if a simple fix can be found.
17-04-2015
Additionally, I've tested it with the latest official binary and the problem still exists. java.version = 1.8.0_45 java.runtime.version = 1.8.0_45-b14 javafx.version = 8.0.45
15-04-2015