On Tue, 26 Jul 2022 11:51:10 GMT, Florian Kirmaier <fkirma...@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

I've just verified that the test is also green with the call to 
`parent.layout()`
So it might be an option, to change this PR to only contain the null check.

When I find some time, I will write a test to show how the parent.layout() call 
can cause issues.
Similar issues exist with Group - which sometimes has the effect, that 
applications stop working when scenic view is used. (or other tooling)

The exception in PrismTextLayout tends to happen when also the bug of this PR 
happens - but I don't really know how they relate.

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

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

Reply via email to