On Fri, 12 May 2023 07:49:29 GMT, John Hendrikx <[email protected]> wrote:
>> I think once there is an unsnapped parent, all children should probably also >> be unsnapped (ie. the property should work like the visible property; if I >> turn it off for one parent, all children become invisible/unsnapped). >> >> There would otherwise be little point in setting a parent to unsnapped if >> one didn't also turn off snapping on all the children. >> >> Note that we tested what happens when you put snapped content in an >> unsnapped container; currently this results in all children to be misaligned >> (not pixel aligned). I think that's the only real solution, as trying to >> resnap your positions when your parent container is misaligning you would >> otherwise need to introduce some kind of flexible border that "absorbs" some >> of the misalignment so the rest of the content can be snapped again... >> >> Basically, there are three strategies for children when dealing with an >> unsnapped parent: >> >> - Just do snapping as normal (JavaFX currently) and when the parent >> translation is added, all final positions will be shifted by an unsnapped >> amount resulting in all calculations (even though they used snapping logic) >> to be in the "wrong" positions >> - Ignore snapping when a parent is unsnapped and use standard calculations >> - Somehow try to resnap content taking the parent misalignment into account; >> this is going to cause visual artifacts as the parent is moved, and requires >> some kind of flexible border > >> In this case getWidth() may not be snapped since the titled pane has been >> laid out by an unsnapped parent. > > And when that happens, you can't do anything about it either. If you adjust > the width, you risk not covering the entire area that the parent gave you (or > more if you round up), and if you use it in any calculations you need to > resnap any values resulting from it, and you would still end up with some > dead space that your snapped calculations can't cover... > > The only real solution seems to be to treat snapping like visibility IMHO. > I think once there is an unsnapped parent, all children should probably also > be unsnapped (ie. the property should work like the visible property; if I > turn it off for one parent, all children become invisible/unsnapped). One complication with this is that the `snapToPixel` property is on `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't have that property. What you describe _might_ be OK as long as you ignore any parent that isn't a `Region` when asking the question "are all my ancestors have `snapToPixel`". > Basically, there are three strategies for children when dealing with an > unsnapped parent: > > * Just do snapping as normal (JavaFX currently) and when the parent > translation is added, all final positions will be shifted by an unsnapped > amount resulting in all calculations (even though they used snapping logic) > to be in the "wrong" positions Right. If a non-snap-to-pixel ancestor lays out it children, then all bets are off. Absent a compelling reason to change it, this seems like a reasonable default (perhaps it should be documented better). > * Ignore snapping when a parent is unsnapped and use standard calculations A change to do this _might_ be OK, with the caveat I mentioned above about non-Region parents, but this would need careful analysis. As part of this, I would want to understand the motivation for doing this (i.e., what is the benefit?). > * Somehow try to resnap content taking the parent misalignment into account; > this is going to cause visual artifacts as the parent is moved, and requires > some kind of flexible border Yeah, this doesn't seems like a good idea. If you want to explore this further, you could file a new RFE to consider making a change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192574561
