On Mon, 24 Feb 2025 20:39:01 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line
>> 2020:
>>
>>> 2018: double baseline = child.getBaselineOffset();
>>> 2019: if (child.isResizable() && baseline ==
>>> BASELINE_OFFSET_SAME_AS_HEIGHT) {
>>> 2020: return top +
>>> snapSizeY(boundedSize(child.minHeight(alt), max, Double.MAX_VALUE)) + bottom
>>
>> here and elsewhere: a wise man once said that the sum of snapped values may
>> not come out snapped. Should we start snapping the result of any algebraic
>> operation that involves snapped values?
>
> LOL, I think I may have said that :) However, perhaps the problem is not as
> bad as I made it out to be. It's definitely true that any operation on a
> floating point value may slightly nudge it away from a true snapped value
> (somewhere in the 10th decimal place) and that this problem gets worse the
> more operations you perform (ie. a HBox with 10.000 children will have a
> worse error than one with only a few children).
>
> But there may be some middle ground possible here. As long as our layout
> containers are aware that values returned from `computeMinWidth` etc are only
> "near" snapped (meaning that if you round them to the nearest pixel, you'll
> always get the right result), it should be fine -- one must take care not to
> immediately call `ceil` or `floor` on these values. A thing we may want to
> look into is how this is rendered on screen by the rendering layer; does the
> rendering do additional work when values are near snapped, or do they perform
> some rounding already anyway. I certainly never noticed these small errors
> resulting in display artifacts.
>
> In any case, this is probably better addressed in a separate effort, and we
> should probably write some guidelines first. I'm hoping to do some of this
> with the space distributor PR.
In theory, all these calculations end up being used by the layoutChildren()
which always (?) snap the values.
So the question is whether this small error gets accumulated enough to shift
the result to a wrong value. Given a typical number of children (<1000) and
screen sizes (<10000), we might conclude that it's unlikely, since
`Math.ulp(1000 * 10_000.0) = 1.862645149230957E-9`
which is much smaller than the distance between pixels even at 1000% scale.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1968398142
