RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4]
John Hendrikx
jhendrikx at openjdk.org
Thu Oct 30 13:37:49 UTC 2025
On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:
>> This new check is much more accurate to detect whether a parent is currently laying out its children. The previous code almost never worked, resulting in additional unnecessary layouts.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>
> Rename test
> What I wanted to say with this is that the _current_ handling gives priority to making sure things got rendered (e.g. adding a second pulse in cases where it's not needed), and not to performance. If you want to change that, all good. I simply tried to give my reading of historical context, while trying to understand why things are the way they are. Again, I'm not saying this should not be modified (rather the contrary). I had the impression you wondered about why it was like it was, and I tried to answer that. Sorry if that message came over a bit hyperbolic.
Sorry, I definitely misinterpreted that and got a bit wound up about it.
I'm however unsure how to proceed. I don't think I can solve all the problems we've been seeing:
- Problem 1: Layout flags not being updated correctly, leading to layouts stop being updated (JDK-8360940) -- fixed by #1879
- Problem 2: The problem Johan Vos posted in the mailing list where layout X/Y **always** gets modified twice, and although it converges to the same value each time, the layout X/Y logic will now always trigger another layout due to #1879 (before it would just get into a state where some things needed layout, but it wasn't propagated)
- Problem 3: The test program that binds on width/height properties in JDK-8137252 -- I'm dubious if that's worth supporting. The fix was to always do a 2nd layout (as the `isCurrentLayoutChild` precondition doesn't actually work)
- Problem 4: The menu bar not working correctly (but that may be fixable)
Without any fixes, 2 + 3 + 4 works.
With just the layout flags fix 1 + 3 + 4 works.
With this PR 1 + 2 will work, and probably can get 4 fixed as well.
With this PR **and** perhaps always triggering another pass if a non-resizable control was modified, we may be able to get all of them working. I however can't really see the logic why non-resizable controls should be an exception here, and if we can't also run into the same problems with a resizable control if I modified the example in JDK-8137252.
:-)
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3468039307
More information about the openjfx-dev
mailing list