On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <[email protected]> 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
