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

[Marius Hanl]

On Fri, 12 May 2023 18:40:20 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).
>> 
>> 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.
>
> @kevinrushforth it probably isn't worth pursuing a change in the child/parent snapping logic right now, at least not without some compelling case. First I think snapping is rarely disabled (I never have, despite working on graphics heavy JavaFX applications).  Second, one can already get the (possibly more) desired situation by taking care all children are unsnapped as well.

I agree with the consensus here. And same as @hjohn, I actually also never disabled snapping. There was never usecase where I needed to do so (And I worked on a lot of UI related things, including creating custom components of all kind).

> 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).

I agree here.The defaultis fine, and it's hard to say what would be a better default 'setting' here (if there really is a better way). Does a developer really expect that all children of a unsnapped node are unsnapped as well? Or is there a usecase where you don't want this? It's hard to answer, so as written above, the default seems fine and logicial.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192780661