RFR: JDK-8269921 Text in Textflow and listeners on bounds can cause endless loop/crash and other performance issues [v3]

[Michael Strauß]

On Tue, 26 Jul 2022 11:51:10 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> It's "a bit" complicated.
>> In some situations, getRuns get's called because listeners on bounds are set.
>> This causes TextFlow to layout to compute the runs.
>> Afterward, the bounds of the parents get updated. 
>> This triggers a call to compute bounds - which cascades up to the children.
>> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
>> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
>> 
>> In the case it happened - it didn't repair and the application kinda crashed.
>> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
>> It also can cause unpredictable performance issues.
>> 
>> Unit test and example stacktrace are in the ticket.
>> 
>> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
>> The Textflow should be layouting by the Parent.
>> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
>> 
>> Benefits:
>>  * Better Tooling Support For ScenicView etc.
>>  * Fixes complicated but reproducible crashes
>>  * Might fix some rare crashes, which are hard to reproduce
>>  * Likely improves performance - might fix some edge cases with unpredictable bad performance
>
> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origjfx/master' into JDK-8269921-textflow-bug
>  - JDK-8269921
>    Added a copyright header
>  - JDK-8269921
>    Fixing a crash related to Text and TextFlow with bounds listeners

For what it's worth, I agree that updating the bounds or synchronizing peers shouldn't trigger a new layout cycle.
Unfortunately, test coverage is not good for the `javafx.scene.text` classes, so we won't catch regressions that way.
Do you think that you can come up with a minimal test that shows a different outcome with or without the call to `getParent().layout()`? If we had that, we could decide with more certainty which behavior we think is more correct.

-------------

PR: https://git.openjdk.org/jfx/pull/564