On Mon, 31 Aug 2026 20:16:21 GMT, John Hendrikx <[email protected]> wrote:
>>> 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) > >> Could we look at this from standpoint of _intent_? What is the application >> intent to have mismatched snapping? > > I can't think of a good use case. There might be use cases for having entire > sub-trees unsnapped, but not for switching a sub-subtree back to snapped > (hence why I'm now of the opinion that we should treat snapping like we > treat visible/disable, toggle it off and it is off for the entire subtree). > >> 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. > > There is no reason to change the snap setting for animations; it will just > create an awkward jump at the start/end of the animation. Animations work by > using translations/scales/rotation etc, which are applied separately from the > layout bounds. So if you have a button that must slide into place, just > apply a translation and it will animate smoothly, with subpixel precision > (and the eye won't notice the button temporarily being rendered at an > unaligned X offset being perhaps slightly blurry unless you screenshot it mid > animation). > > When the button settles into place, it will be exact pixel aligned again > (when translation goes to 0). If you toggle snapToPixel at the last moment, > the (entire) layout may jump slightly which will be visible to the naked eye, > ruining your animation. > >> What could be the other scenarios? Especially those that involve unsnapped >> parent and snapped child, or when no movement is expected? > > I can't think of any; even using unsnapped for an entire subtree (or using > unsnapped at all) seems a stretch for anyone to ever need. Perhaps for > "tiny" controls (close to pixel sized) where a full pixel more/less would > ruin the look. Anything beyond a size where the user can interact with it > (say 10+ pixels) seems ridiculous to use unsnapped. I wonder, why do we even need the unsnapped setting? what is the use case? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3898547875
