Bug ID: JDK-8117334 Some Nodes in a Group can paint outside the clipping bounds

Type: Bug
Component: javafx
Sub-Component: graphics
Affected Version: 7u21,8

Priority: P3
Status: Closed
Resolution: Cannot Reproduce

Submitted: 2013-05-22
Updated: 2015-06-17
Resolved: 2013-08-26

JavaFX 8.0-b90
(also JavaFX 2.2.21)

Nodes in the scenegraph will occassionally render outside of the area if the clip shape.  A simple Rectangle is being used as a clip shape.  I have a complex set of nodes in an AnchorPane.  The clipping rectangle and the anchor point of the Group that is contained in the AnchorPane are adjusted simultaneously to scroll view of the Group.  Some nodes that are deep within the node hierarchy of the Group will paint outside the AnchorPane.

Submitter is confident that the fix for RT-30223 will have fixed this problem as well and recommends closing this bug as no longer reproducible.
26-08-2013
JDK 8-b102 has been promoted. Does it fix this problem?
14-08-2013
I think the point about the comment about 8-b102 is that since a test case for this bug was never submitted, it is still conjecture that this is a dup of RT-30223. To be clear, the fix for RT-30223 is in 8b102. If you can verify that build fixes this problem (or the appropriate 7u40 build), then we can close this as a dup of 30223. It's probably more likely that you will see an 8-b102 build before a 7u40-b37, but I don't know the particular schedules...
04-08-2013
Excellent. And more importantly for people shipping apps this year.. I see that there is an effort to get it into 7u40. That is very much appreciated.
03-08-2013
The fix should be in JDK 8-b102.
03-08-2013
The next promoted FX8 build should confirm if that is the case since the fix for RT-30223 was pushed to the graphics scrum today. Unfortunately, the next integration from the graphics scrum may be next Tuesday.
31-07-2013
Looking again at the documents where this occurs, even in the attached screeenshots, the node labeled JavaFX Preview DOES have a Canvas node. I think this is the case! That's good, since we can't use the Canvas node in production anyway until the unbounded queue is fixed. Previewing video in a Canvas is a sure way to run out of memory. I aways wonderd why I could only reproduce this with some documents - the Canvas node used by the preview component explains that now. I think it is safe to close this as a duplicate of RT-30223.
31-07-2013
Could this be a duplicate of RT-30223? Is the application using Canvas nodes anywhere? Does the problem go away if the Canvas nodes are replaced with some other type of node?
31-07-2013
See video here http://www.screencast.com/t/8Syrqp5nz
31-07-2013
The j2d pipeline works for JavaFX 2.2.21, thanks. But it too causes the my StageStyle.TRANSPARENT Stage used as a splashscreen to not appear at all. There are also subtle rounding differences where I can see sub-pixel leaks of colours around the borders of some nodes, but I think that appeared to a lesser degree with the HW pipeline as well. I'm sorry,I have not isolated this into a test app. My test app is large and complex so isolating a test app may take some time. I can say that it is 100% reproducible. It is always the same nodes that draw the same way. I suspect they are the last few nodes to be added to the scene.
23-05-2013
The sw pipeline is 8 only. You can use the "j2d" pipeline on FX 2.x.
23-05-2013
Also note that I have a splashscreen that uses a TRANSPARENT Stage. It doesn't appear at all with -Dprism.order=sw
23-05-2013
I need something that works for JavaFX 2.2.21 on Java 7u21... Is there a way to get the software pipeline in JavaFX 2.2.21? Right now I get this: Graphics Device initialization failed for : sw Error initializing QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
23-05-2013
I can confirm that the issue goes away with -Dprism.order=sw
23-05-2013
Oh, I see that you already mentioned that above. The dirty region bug is probably the same as RT-30220 which will be fixed in next week's build, but that won't help here (other than it should eliminate the need for you to turn off dirtyopts). Do you have a test app that shows this bug? Can you try it with the software pipeline to see whether it is a HW pipeline specific bug: -Dprism.order=sw
23-05-2013
Note that the screen shots are from a run with -Dprism.dirtyopts=false It looks much worse without that.
23-05-2013
I already did - read my second comment.
23-05-2013
Can you try with: -Dprism.dirtyopts=false ?
23-05-2013
I also just tried with -Dprism.disableRegionCaching=true but it had no effect.
23-05-2013
If there are any properties I can set to alter the graphics pipeline that may help work around this, please let me know. I am already using -Dprism.disableD3D9Ex=true to work around RT-27121 and I have tried -Dprism.dirtyopts=false which does have an effect.. normally the rendering that escapes the clipping region would leave trails as I scroll content, but with that property set the other nodes in the UI will properly repaint so the trails are gone, even though the "escaped" node is still painting on top of them. This issue happens in both Java7u21 (JavaFX 2.2.21) and Java 8 (JavaFX 8.0-b90). I would really like to see a fix in 7u40 if possible as we are already shipping this with the JFXPanel. The issue is realtively contained in the JFXPanel version of our app because the nodes can't get outside the JFXPanel. For the full JavaFX conversion this is a significant showstopper, as the Node can render over anywhere in the UI. We had hoped to ship the app fully converted to JavaFX in a month or two (99% of the work is complete). That doesn't look possible now, so if there is a workaround I would love to know.
23-05-2013
The fact that only some nodes are rendered outside of the clip suggests that Scenegraph reports the clip correctly. Assigning to Graphics.
23-05-2013
Note that Label and Text, and Button nodes contained within the Node that renders outside of the clipping area ARE clipped to the correct bounds. But sometimes when they get all the way out, the Button backgrounds appear again, with the text still missing. Screenshots on the way.
22-05-2013