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

[Andy Goryachev]

On Fri, 25 Nov 2022 08:12:49 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> I also never understood that completely.
>> Hence I asked at the mailing list about snapping in the past: https://mail.openjdk.org/pipermail/openjfx-dev/2021-September/032166.html
>> In my opinion it also makes sense to snap the values once. But that would be a huge refactoring and everything is affected. We can not just change this now. Thats why I would stick to the existing solution and refactor that later.
>> But some clarification here would be helpful here, maybe ask the people who created this (if available)?. And I haven't looked yet, but how does Swing handle this?
>
> It's seems little tricky to choose an approach for this fix.
> 
> - NOT snapping intermediate values (new approach):
> 1. It definitely seems correct NOT to snap intermediate values.
> 2. But currently, code Controls snap the intermediate values,
> 3. This PR seems to be the first change of snapping in a layout:
> => Will it regress if we have different approach in layout than in control ?
> I think No, It won’t regress. @Maran23 Can you please try it with this fix ?
> In that case, we can adapt the new way for layout and file a new JBS to refactor existing code.

I think I now understand the snapping better, especially after discussion in https://github.com/openjdk/jfx/pull/1111

it looks like we should be operating in terms of final pixels, that is, in snapped coordinates.  this might mean what we should not, generally, mix snapped and unsnapped values:

result = snap(a) + snap(b); // ok

result = snap(snap(a) + b) // also ok

result = snap(snap(a) + b + c) // not ok, should be written as
result = snap(snap(a) + snap(b) + snap(c)) or
result = snap(a) + snap(b) + snap(c)

What do you think?

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

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