JDK-8172364 : Ensemble8 Canvas Fireworks jitters while animating
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-01-06
  • Updated: 2017-02-02
  • Resolved: 2017-02-02
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 9
9Fixed
Related Reports
Duplicate :  
JDK-8170317 - TextFlow is layed out on each pulse
Relates :  
JDK-8170317 - TextFlow is layed out on each pulse
Relates :  
JDK-8137252 - JavaFX StackPane bounds not updated
Description
To reproduce this:

1. Run Ensemble8

2. Select the "Graphics 2d" --> "Canvas Fireworks" sample

The position of the Canvas in the Ensemble window will jitter as it is animating. It appears to be jumping between two different positions each frame, as if the layout calculation returned a different answer each frame.

This is more noticeable on slower systems or when the SW pipeline is enabled. I have seen this on both Linux and Windows. I have not tried it on Mac, but I suspect it is platform-independent.

This is a regression. It works in the latest JDK 8u release and fails in JDK 9.
Comments
Changeset: 9ef943527049 Author: ckyang Date: 2017-02-02 11:42 -0800 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9ef943527049
02-02-2017
+1
02-02-2017
Please review the proposed fix. This fix is essentially a minor revert of the fix that went into JDK-813752. In theory the fix was correct but doNotifyLayoutBoundsChanged() is called by many placing when there is a change geometry or position in the current implementation. It seems like we might have cases where request layout shouldn't be called. However to differentiate which case requires layout processing on its parent even if its parent is already in the performing layout phase will require much intrusive fix (assuming we have a test case). Since we don't have reported bugs on these cases the safer fix is to make the line revert: http://cr.openjdk.java.net/~ckyang/JDK-8172364/webrev.00/ I have verified that this change didn't break the fix for JDK-813752 and it also passes full build test on all 3 platforms.
01-02-2017
Bisecting within the build I get this: The first bad revision is: changeset: 9620:6ef9d5c0ad46 user: ckyang date: Fri Mar 11 14:37:23 2016 -0800 summary: 8137252: JavaFX StackPane bounds not updated So this is a regression introduced (or exposed by) the fix for JDK-8137252.
06-01-2017
I bisected the JDK 9 promoted builds and discovered that this was introduced in jdk-9+112. 8u112 - works 9+111 - works 9+112 - fails 9+151 - fails
06-01-2017