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

[Andy Goryachev]

On Sat, 22 Apr 2023 09:38:46 GMT, John Hendrikx <jhendrikx 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.

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.

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.

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

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