On Mon, 8 May 2023 19:04:01 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> 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? I agree but that is also what I do here, isn't it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1191590759
