On Mon, 31 Aug 2026 12:35:03 GMT, Michael Strauß <[email protected]> wrote:
>> 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? I think that 2nd one as it is also the simplest (don't touch provided x/y/w/h). Reasoning: - parent is unsnapped - parent therefore provides unsnapped x/y and w/h - snapped children don't touch x/y but just go with it - if x/y is not being corrected, then why should w/h be? With an unsnapped x/y, the child is already going to look terrible, may as well use the (matching) unsnapped w/h. Technically I think it also makes sense enough; the parent owns the x/y and w/h dimensions, and they were unsnapped. Second guessing that undoes what the parent wants. For the child's internal structure, it can place things snapped again. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3895582702
