RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v7]

[John Hendrikx]

On Wed, 26 Apr 2023 18:37:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > The min/max values are not strictly honored when snapping is on, they're snapped first.
> 
> [question]
> 
> Here is a general question: in the case when min==max, in which direction should we snap? Could this question be answered all the time, or do we need some sort of hint from the app developer?
>
> For example, we may decide to honor min width over max width when snapping, to avoid text overruns in labels and buttons. At the same time, there might be situations where max width is more important, I just can't think of any.

In UI layout, it's pretty standard that min always wins over max, and that's also what JavaFX is doing (see the `boundedSize` function in `Region` that handles this).  Here is how it is called when calculating the max value for `HBox`:

        // if min > max, min wins, so still need to call boundedSize()
        return left + snapSizeX(boundedSize(child.minWidth(alt), max, Double.MAX_VALUE)) + right;

The above basically returns `max` only if it is within the given range of `minWidth` and `Double.MAX_VALUE`, otherwise it is clamped to one of those two values.

Also, the developer already has full control over the behavior. If the snapping is not to their liking, it can be disabled and values can be manually calculated using the public snapping functions or by querying render scale themselves. I see no need to complicate this already complicated process even further as the current behavior is I think what the most developers will expect (ie. content sizes are ceil'd so you always get at least 1 pixel (unless 0), and spaces are rounded as they're less important).

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

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1524011324