On Sun, 16 Aug 2026 00:43:27 GMT, Michael Strauß <[email protected]> wrote:
> `Region.layoutInArea()` calls `Region.boundedNodeSizeWithBias()`, which > derives the dependent value from a potentially unsnapped value, after which > `layoutInArea()` assigns a potentially different, snapped value to the child. > This is wrong, because the dependent value is effectively computed against a > value that might not be assigned to the child. > > For a horizontally biased child, the current sequence is effectively: > > > double rawWidth = boundedSize(...); > double rawHeight = boundedSize( > child.minHeight(rawWidth), > ... child.prefHeight(rawWidth) ..., > child.maxHeight(rawWidth)); > > child.resize( > snapSize(rawWidth), > snapSize(rawHeight)); > > > The correct sequence would be: > > > double width = snapSize(boundedSize(...)); > double height = snapSize(boundedSize( > child.minHeight(width), > ... child.prefHeight(width) ..., > child.maxHeight(width))); > > child.resize(width, height); > > > This snapping bug can only be observed when all of the following conditions > are met: > 1. pixel snapping is enabled > 2. the child is resizable and has a horizontal or vertical content bias > 3. the bounded primary dimension is not already correctly snapped > 4. the dependent size constraints change between the raw and snapped primary > dimensions > > This came out of the "snapping rules" I've compiled for PR #2260, > specifically the rule [Use the same snapped dependent dimension for > measurement and > layout](https://github.com/openjdk/jfx/pull/2260/changes#diff-3fe4ab83269e3ae0ec167ebe622893aff218168e7cab666e5a64c99e6dfbfd4fR464). > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Will review soon, but I agree that this makes sense. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2261#issuecomment-5305679459
