On Fri, 12 May 2023 16:20:35 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
>>> 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. I think it's probably not worth doing. When the application developer sets snapping off when it's on by default, they do it for a reason, so the current behavior is the right one. May be they want to smooth some transition during animation (a-la scrolling ticker tape), who knows. FX gives this choice at per-Region basis for this kind of flexibility, otherwise there would be one global setting, right? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192625442
