RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4]

[Kevin Rushforth]

On Fri, 12 May 2023 07:49:29 GMT, John Hendrikx <jhendrikx at openjdk.org> 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