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

[John Hendrikx]

On Mon, 24 Apr 2023 16:30:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > I think a single pass algorithm should be possible.
> 
> In some simple cases, yes. But not in all possible cases.
> 
> Let's consider one example, a layout similar to TableView.CONSTRAINED_RESIZE_POLICY_ALL_COLUMNS. When we need to distribute extra space and at least one column (or a Node in a layout) hits its maximum size constraint, all the computations must be discarded and re-done using the maximum width for that node. Since now we have more space to re-distribute, another node might hit its maximum constraint, and so the process must be repeated.

But that's exactly what HBox already does.  And you don't need to discard anything, you just continue but skip nodes that have already reached maximum and distribute the remaining space.

> The situation is even worse when we have a fractional scale: the computation must be discarded and re-done not only if one node hits a constraint, but even when it gets moved. Moving a node may not only require us to change the (already computed) width of that component, but also change the remaining delta, which basically invalidates the whole thing.

The start position of the Node should not influence the width or space available, see below.

> And finally, I doubt it is possible to use the trick mentioned in the preceding comment - by converting to and computing in the scaled coordinates, for a simple reason - the constraints are set in the original, unscaled and unsnapped coordinates. When you try to convert a constraint to scaled and snapped coordinates, the constraint is not an invariant, that is it changes depending on where the node is positioned.

I'm sorry, I don't quite see what you mean here, perhaps this is unique to the TableView layout. The constraints are rounded up to the nearest pixel boundary (even the maximum one).  They must be as it would not be possible to render both the left edge and right edge of a control on a pixel boundary if constraints weren't rounded.  The position is also always on a pixel boundary. The start position of a control has no bearing on the rounding of the constraint to pixels, as pixels are all equally wide.

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

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