RFR: 8295078: TextField blurry when inside an TitledPane -> AnchorPane [v4]
Andy Goryachev
angorya at openjdk.org
Fri May 12 17:21:58 UTC 2023
On Fri, 12 May 2023 16:20:35 GMT, Kevin Rushforth <kcr at 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
More information about the openjfx-dev
mailing list