<div dir="ltr"><div>I recently noticed a performance degradation in a JavaFX application, that I could trace to the fix for JDK-8360940 [1]. I believe the fix is correct, but it can cause infinite pulses in some cases. It is somehow discussed in the second of the 2 errors in Parent, in [2], but I believe this pattern is used often, and will now lead to infinite pulses</div><div><br></div><div>For example, a class extending Parent and implementing layoutChildren that does something like this:</div><div><br></div>@Override <br>protected void layoutChildren() {<div>    super.layoutChildren();</div><div>    if (someSpecificCondition) {</div><div>        someManagedNode.relocate(someX, someY);</div><div>    }</div><div>}<br><div><br></div><div>Support the someManagedNode is at (x0, y) before the pulse runs.</div><div>The call to super.layoutChildren() will set the layoutX/Y to e.g. superX, superY and it will request a new pulse (in case superX != x0 or superY != y).</div><div>Next, the someManagedNode is conditionally repositioned to someX, someY .</div><div>In the next pulse (immediately following this pulse), the super.layoutChildren will again set the layoutX/Y to superX, superY, and trigger a new pulse, no matter what happens afterwards. The conditional code will again reset the layoutX/Y to someX, someY (which is what they had before this pulse started layoutChildren()), but the next pulse is scheduled AND it will visit this Node.</div><div><br></div><div>Even though in the end the layoutX/layoutY properties of someManagedNode are not changed as the result of layoutChildren, a new pulse will be requested because there was an intermediate value (which never got rendered, as it was changed again even before the layoutChildren returns) that triggered the requestNextPulse.</div><div><br></div><div>I think this pattern is used in a number of external controls. It worked "by accident" until the issue in JDK-8360940 was fixed. In defense of the pattern above, one could argue that a requestPulse should only be triggered if the triggering property was altered at the end of the layoutPhase (that is, if there is a difference in value between the start and the end of the layoutPhase).</div><div><br></div><div>In summary, I don't propose to change anything, and I agree with the commit in [1], but it might need some attention in the release notes or docs.</div><div><br></div><div>- Johan</div><div><br></div><div><br></div><div>[1] <a href="https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5">https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5</a></div></div><div>[2] <a href="https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022">https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022</a></div></div>