On Tue, 1 Sep 2026 19:29:56 GMT, Michael Strauß <[email protected]> wrote:
> > The rest of your argument is the same. If your unsnapped parent didn't set > > your x/y to be on the grid, then nothing you can do as a child will get you > > aligned back. I think you even said as much in the snapping docs. > > This is why I think we shouldn't bother at all with this, and treat any > > unsnapped ancestor as final for that subtree. > > Yes, this is explicitly called out in the documentation. That's why I think > the only reasonable interpretation for "grid-aligned" can be: relative to the > coordinate system of the parent. Pixel-snapping doesn't work on a global > grid, the snapping algorithm doesn't have the information to do this. > > (And it wouldn't even be useful: as it currently stands, disabling > `snapToPixel` on a region allows you to position its subtree with arbitrary > precision. If instead snapping worked on a global grid, then what purpose > would the `snapToPixel` setting even have? Descendants would still remain > snapped to the global grid regardless of how the parents laid them out.) This is true, I thought you thought we could get grid aligned snapping back. > As another example, let's use a HBox with an allocation of 100 pixels, and > three equisized children. Each child will get an unsnapped allocation of > 33.333; with snapping, two children will get 33 and the last child will get > 34. This gives us perfectly snapped children _relative to the parent_. > > Now the HBox gets an allocation of 100.25 instead. If I understand you > correctly, you propose to distribute the remainder in this way, depending on > `HBox.alignment`: > > * left: the remainder is inserted as trailing empty space > * right: the remainder is inserted as leading empty space > * center: the remainder is equally distributed between the gaps between all > children > > This seems like a complication of the layout algorithm (and I don't know why > I would ever want to control the distribution of the remainder), and we would > end up unnecessarily shifting children out of alignment. If we want to accept > the provided allocation, it seems easier to me to special-case the trailing > edge, but keep the rest of the layout in place. I know I initially said that rounding/ceiling could leave a tiny gap or overlap. However, I now feel that we should not bother trying to fix the transition from unsnapped back to snapped: - Nobody is going to use this, fixing and testing these issues for every skin/container that may be placed directly in an unsnapped container is IMHO a big waste of time - If a gap/overlap does appear that is bothering someone, they can turn off snapping for the entire subtree. We never specified how the transition from unsnapped to snapped is supposed to work or even could work. The solution I presented with leaving the "extra" space based on alignment (as that's how HBox normally does this) is also unsatisfactory, and I think assigning it to the last child (if it happens to extend that far, it may not) is also just additional code paths that nobody cares about. So I'm sort of proposing we either ignore this completely (just pretend you're in a snapped container, and do the thing you would normally do, and if that doesn't work well for unsnapped->snapped, too bad). Or: make snap-to-pixel inherit; you can turn it off, but you can't turn it back on again in a subtree. The current documentation for snap-to-pixel is loose enough that either interpretation works. > Going with the example where we were provided 100.25 pixels, we could lay out > the children on a snapped allocation (exactly 100 pixels), and then add the > remainder to the edge of the trailing child. If the allocation was 99.75 > pixels, we would subtract the remainder from the edge of the trailing child. > Isn't this the easiest solution? It still requires work that I don't think we should be doing; it would be much more sensible to have snap to pixel off for complete subtrees -- nobody will want to turn it back on again as it won't restore alignment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3908299394
