performance impact of JDK-8360940 in case of a wrong but common pattern

[Johan Vos]

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

For example, a class extending Parent and implementing layoutChildren that
does something like this:

@Override
protected void layoutChildren() {
    super.layoutChildren();
    if (someSpecificCondition) {
        someManagedNode.relocate(someX, someY);
    }
}

Support the someManagedNode is at (x0, y) before the pulse runs.
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).
Next, the someManagedNode is conditionally repositioned to someX, someY .
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.

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.

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).

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.

- Johan


[1]
https://github.com/openjdk/jfx/commit/5682424bebae7947f665fcb11429c3d2e069e8e5
[2] https://bugs.openjdk.org/browse/JDK-8360940?focusedId=14811022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20251021/89fa96fd/attachment.htm>