JDK-8125139 : Multiple, overlapping Canvas/Nodes in one pane: rendering sequence problems
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 7u6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2012-11-11
  • Updated: 2015-06-17
  • Resolved: 2013-11-13
Related Reports
Duplicate :  
JDK-8116038 - Canvas in BorderPane centre component can cause buttons in bottom component to disappear
Duplicate :  
JDK-8115150 - Canvas clip not working properly on Windows
Relates :  
JDK-8103438 - Canvas should clear its buffered commands on certain clearRect, fillRect calls
Description
I have the following issue:

1 Outside pane, inside the following components in the following sequence:
...(1) Canvas (0,0,100,100)
...(2) Button (0,0,100,30)
...(3) Canvas (90,90,100,100)
...(4) Button (90,90,100,30)
So there is an overlapping area of 10x10 between (1),(2) and (3),(4).

When moving with the mouse over (4)-Button then the (1)-Canvas is drawn over the (2)-Button - which is not correct.

It seems to me like a rendering-sequence/dependency-issue: moving the mouse re-renders (4)-Button, triggering a re-rendering of (1)-Canvas because of overlapping, but (2)-Button seems not to be re-rendered.

I attached a demo program showing the effect.
Comments
This is essentially a dup of RT-30223. The bug is no longer reproducible in 8.0 and 2.2.40, but removing the fix for that other bug causes this bug to reproduce. I recommend updating to the latest version of 2.2 and the problem should go away. If not, let us know and we can reopen this issue.
13-11-2013
This might already be fixed by RT-32242. Assign to Jim to verify.
06-11-2013
This code is in flux at the moment, since canvas is broken when updating it's dataBuffers. I am worried that pending updates via a second dataBuffer might overwrite dirtyRegions, i guess the canvas would still be "dirty" in this case.
07-10-2013
Yes, I did miss those earlier comments. Sorry about that. Assigning back to Joe.
13-11-2012
Kevin, you probably missed my second comment where I wrote that setting dirtyopts to false is a working workaround. We looked at the issue with martin. Dirty regions are correct. Canvas rendering ignores them.
13-11-2012
Thanks for the confirmation. Martin: can you take a look at this?
13-11-2012
FYI: With applying "-Dprism.dirtyopts=false" the rendering is correct.
13-11-2012
This might be a dirty region optimization bug. Please try with: java -Dprism.dirtyopts=false to see if that makes a difference.
13-11-2012
A workaround is switching off dirty regions by VM argument "-Dprism.dirtyopts=false". Please note that this workaround may be used for the developers to avoid the problem until it's fixed, but you don't want it to be used for production as it has serious performance implications.
12-11-2012
This looks like a canvas issue - if the canvases are replaced by rectangles it starts to work normally. Canvas most probably fails to work with dirty regions - when the mouse enters (4)-Button, in the entire scene only this button becomes dirty, so nothing else should be rendered. But the canvas is rendered (even though it is not dirty), and it covers the (2)-Button, because this button is also not dirty so it is not rendered (which is correct). To sum up the clumsy explanation: canvas seems to render even when it's not dirty which causes the scene to be rendered wrong.
12-11-2012