On Thu, 27 Aug 2026 22:17:41 GMT, John Hendrikx <[email protected]> wrote:
>>> I'd expect `snapSize` really, since the minimum width is the size of the >>> content. >> >> This is the available size, not a content allocation. For example, if the >> pane has an available size of 100.01, then we shouldn't snapSize this value >> and arrive at an available size of 101. > > Ah, I thought this was a call to some child... > > So what we have here is that the border pane is given some width by its > parent (say 100.34) and then instead of living with that value, border pane > decides that ain't good enough and replaces that with its own min width > calculation (which the parent should have taken into account already). I > would think a plain `Math.max` would suffice here; rounding it just runs the > risk of going below the width set by the parent. > > I never quite liked this code, and I still think it's odd that BorderPane is > one of the few layouts that is 2nd guessing what the parent sets for it. > > But is pre-existing; I just wonder if rounding this is a good idea at all, as > you may go below the actual width given and thus create a gap in between > components that has nothing filling it. So if minWidth is only 90, then it > will take 100.34 -> 100.0 after rounding, leaving a .34 pixel gap that may > show up in some bright color from some background leaking through. This is the situation described in the guideline under _Deliberately apply the snapping policy to values determined by the parent_. We've established that each region owns the sizes it allocates to its children. This means there's an unavoidable conflict when a child is given a non-aligned content allocation, but its own `snapToPixel` is `true`. We basically have these options: 1. The child snaps its content allocation to the pixel grid: * ...with `ceil`: the content will never underflow, but it may overflow by up to 1 px. * ...with `space`: the content can overflow or underflow by up to 0.5 px. 2. The child doesn't snap its content allocation and honors it perfectly: * there will be no gap between adjacent regions * but at least one child must be non-aligned even though `snapToPixel` says that all children are aligned Which of these do you prefer? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3894491119
