On Mon, 31 Aug 2026 20:01:33 GMT, John Hendrikx <[email protected]> wrote:
>>> 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) Could we look at this from standpoint of _intent_? What is the application intent to have mismatched snapping? One possibility is some kind of transition/animation where the whole thing slides from one place to another, so the parent is snapped and the child might be not snapped for the duration of the transition. What could be the other scenarios? Especially those that involve unsnapped parent and snapped child, or when no movement is expected? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3897930292
