On Sun, 6 Sep 2026 21:59:12 GMT, Michael Strauß <[email protected]> wrote:

>> This PR is an audit of several snapping-related methods in `Region`, along 
>> with some bug fixes.
>> 
>> I've added a helper method `snapAligned()`, which does the exact same thing 
>> as `snapSpace()`, but clearly states that the author knows that the value is 
>> already pixel-aligned. In addition, I've renamed several local variables 
>> around a "rawFoo" and "snappedFoo" naming scheme, so as to make it easier to 
>> see what's what.
>> 
>> This PR should probably be integrated before the other layout container PRs, 
>> because those use the `Region` layout methods.
>> 
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the 
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Michael Strauß has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - revert
>  - review comments

`layoutInArea` is such a broken method, but I've decided that unbreaking it is 
out of scope for this PR.

Within `layoutInArea`, the resizable child's baseline is queried, then this 
value is used to determine its size allocation, and after that is done, the 
`position` method re-reads the child's baseline _which could be totally 
different now_ to position it. Passing the pre-resize baseline to `position` 
doesn't work either:
1. Reading twice (current): final baseline is correct, but the size allocation 
may be inconsistent.
2. Reading once: size allocation is consistent, but the final baseline might be 
wrong.

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

PR Comment: https://git.openjdk.org/jfx/pull/2278#issuecomment-5562513329

Reply via email to