On Mon, 31 Aug 2026 20:04:09 GMT, Andy Goryachev <[email protected]> wrote:
>> 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? > So my conclusion: or 3. the boundaries passed to the snapped child(ren) are unsnapped, but the internal boundaries are snapped parent: U-----------U children: U---S---S---U (U = unsnapped, S = snapped) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3897949169
