Re: RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4]

[John Hendrikx]

On Mon, 27 Oct 2025 14:44:44 GMT, John Hendrikx <jhendr...@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

> First of all, I would like to thank you John for looking into the layout 
> problems. We've got these long standing issues that are very difficult to 
> debug and fix.
> 
> I think this is valuable work as it definitely improves the platform, so 
> Danke schön.
> 
> The reason I asked about tests and test scenarios is the possibility of 
> regression. Case in point - with this PR, on macOS with an external monitor 
> at scale=1:
> 
> <img alt="Image" width="1184" height="340" 
> src="https://private-user-images.githubusercontent.com/107069028/506202288-f55f0c01-c59a-49b5-8fc6-91470524eb9a.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjU2NTgxODQsIm5iZiI6MTc2NTY1Nzg4NCwicGF0aCI6Ii8xMDcwNjkwMjgvNTA2MjAyMjg4LWY1NWYwYzAxLWM1OWEtNDliNS04ZmM2LTkxNDcwNTI0ZWI5YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjEzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIxM1QyMDMxMjRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zZTcyM2IzNDU2MTMzYzJmYTk4OTEwNDRjNGU0ODZmNTQ1YjZkZjk5MDc3NWJiNWFlZWQ5MDQ3YzUzZjZiMmIxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.be1JMTnxYZCqdktvyRJndSqj_PtKX5Hl2_e71hPRK4I";>
> I would second @johanvos in suggesting that the regression is what we should 
> be guarding against, and perhaps expanding the tests.

@andy-goryachev-oracle 

I've had access to a Mac for a bit, and I attached my 4K screen to it and set 
it to full resolution (which makes it scale=1).

What I found is that MonkeyTester indeed shows the bug with this change.  
However, I am now convinced that it is more of a coincidence, as I can 
reproduce the bug also without this change.  In other words, there is a bug, 
and this one change just happens to make it more obvious in the MonkeyTester 
case.

What it looks like is that the render scale is not set correctly for a short 
time, causing calculations (and roundings) to be done with the wrong render 
scale. I created a small sample with an HBox and 3 labels (as I've already 
narrowed it down to labels; it is not the MenuBar, it is not the MenuButtons, 
it is not Buttons, it's Labels).  What happens is the following timeline:

- RenderScaleX = 1.0 (default value I guess)
- RenderScaleX becomes 2.0 (perhaps that's the built-in screen render scale)
- Three labels get asked their horizontal sizes; they round these results to 
multiples of 0.5 ->  (19.0, 43.5, 117.5)
- These sizes are used by HBox to set its width (it becomes 231.0 pixels label 
widths + padding 3x 17.0)
- The layout pass finishes and the three labels are laid out (they get the 
horizontal sizes 19.0, 43.5, 117.5) **correct**
- RenderScaleX becomes 1.0
- The labels get asked their sizes; this time they round these to multiples of 
1.0
- The HBox is **not** adjusted
- The labels are laid out again, but they get sizes that are slightly too 
small: 17.0, 43.0, 117.0 **incorrect**

The conclusion here is that this is entirely expected as HBox is not being size 
adjusted the 2nd time, and so has to render 3 labels with slightly too little 
space. The result is that all 3 labels get an ellipsis.

This same thing happens for the MenuBar (it is basically a HBox with Buttons in 
it which are primarily labels).

So questions to ask:

- Why is render scale being adjusted twice?
- Why are layout calculations being done when render scale is not yet final?
- Why isn't all layout invalidated after a render scale change so HBox's size 
gets recalculated?

Things that are likely unrelated:
- The target monitor render scale is likely not relevant, it can occur with any 
other render scale, if there is a difference between primary screen and the 
target monitor; it just happens to show up much easier when going from scale=2 
to scale=1 due to larger calculations differences that are not "absorbed" by 
snapping of the values.
- The MenuBar, Labels, Buttons, HBox; they all seem to be doing what they 
should be doing
  - I did notice that LabeledSkinBase is not snapping values of its text size 
calculations and is mixing snapped and unsnapped values (similar to 
https://bugs.openjdk.org/browse/JDK-8370652 ) but that's not the primary cause 
of the problem; I was worried that on Mac the text size calculations may have 
been "unstable" (until they're rendered on screen) but they return the exact 
same values both before and after the render scale changes.

The answers are likely to be found in how `sizeToScene` does things...

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

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3650745910