On Mon, 31 Aug 2026 18:07:10 GMT, Michael Strauß <[email protected]> wrote:
>> 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.
>
>> For the child's internal structure, it can place things snapped again.
>
> This is the entire question here. We're not talking about how a region draws
> its background and border, we're only talking about how it lays out its
> children (i.e. its internal structure).
>
> If you say that a region would snap its children, then that's option 1: the
> region first snaps its allocated size, then it lays out its children within
> this allocation. Option 2 would be that a region doesn't snap all of its
> children, but makes a deliberate decision which child is left unsnapped so
> that it exactly fills its allocation.
>
> Each layout container must decide this based on its own logic. For example, a
> BorderPane would probably leave the top, bottom, and right children
> unsnapped, but snap the left and center child. An AnchorPane would probably
> snap children in the general case, but it wouldn't snap a right-anchored
> child that is anchored with distance 0 to the right side of the allocation.
> So far, none of the layout containers answer those questions deliberately.
I don't understand.
- HBox (unsnapped) 41 pixels wide
- Child 1 gets 10.25 pixels, x = 0
- Child 2 gets 10.25 pixels, x = 10.25
- Child 3 gets 10.25 pixels, x = 20.5
- Child 4 gets 10.25 pixels, x = 30.75
If that cascades down further, then snapping of the child matters:
- HBox (unsnapped) 41 pixels wide
- Child 1 gets 10.25 pixels
- Child 2 gets 10.25 pixels
- HBox 1 (unsnapped) gets 10.25 pixels
- Child 1 gets 5.125 pixels
- Child 2 gets 5.125 pixels
- HBox 2 (snapped) gets 10.25 pixels
- Child 1 gets 5 pixels
- Child 2 gets 5 pixels
- (empty space within border of 0.25 pixels)
- Empty space location determined by alignment
- LEFT: C1 C2 (0.25)
- CENTER: (0.125) C1 C2 (0.125)
- RIGHT: (0.25) C1 C2
Note that empty space for an HBox is nothing unusual. If no children are set to
grow, that is already the case. This is just an additional case here where even
with children set to grow there may be some small bit of unused space, which
can be dealt with similar to the case when the children can't cover the
available space.
The problem though: nothing works this way; space is also snapped so at best we
get something that upon resizing will jitter with an unused pixel when there is
some unsnapped container in the hierarchy which has nested snapped containers.
The reason why nothing works that way: nobody uses this; everything is always
snapped, and only for animations (which don't use layout positions anyway) is
it relevant that you can have sub-grid precision.
So my conclusion:
1. We can spend a ton of effort getting some semblance of sanity in how a
snapped child/container/region should work when placed directly in an unsnapped
container, even though nobody uses it ever, and even though we'll probably not
reach an agreement on what is "sane" -- when resizing you are likely to see odd
jitter/gaps no matter what choice you make here
2. We can alter snapToPixel behavior to a more sane way of working, that is: if
this container or any ancestor is unsnapped, then this container behaves
unsnapped (ie. it cascades like visible/disabled)
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3897911805
