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

[Andy Goryachev]

On Tue, 25 Apr 2023 07:49:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> It's logical width can take on any multiple of the physical pixel size divided by the render scale, which is 1 / 1.5 = 0.66.

No it cannot.  Snapping imposes limitation on which logical coordinates are acceptable.  What's more, the distance between two adjacent acceptable logical coordinates is not the same.

Let's take a look at an example.  We are going to use logical coordinates only, because these are used for constraints as well as in the layout.  Here is a list of acceptable snapped logical coordinates for scale=1.5 again:


scale=1.5
x=1 snapped=1.333 step=1.333
x=2 snapped=2.000 step=0.667
x=3 snapped=3.333 step=1.333
x=4 snapped=4.000 step=0.667
x=5 snapped=5.333 step=1.333


(the fact that x are integers is irrelevant, we are not limited to integers, it's just to illustrate a point).

So let's have two nodes with fixed size of 1 (min = max = 1).  The first one is positioned at x=0 and has the width of 1.333.
The second is positioned at x=1.333 and has a width of 0.667.

One surprising effect of this (that we haven't discussed yet) is that both min and max constraints cannot be honored (this might impact some tests).

But let's move to the main point.  Imagine that we have more nodes, and as the layout progresses, we discover that one or more nodes hit the max constraint.  And let's imagine that the node that gets extra space is the first node.  So the first node gets wider (width = 2.0), then the second node is moved and its width must change to 1.333.  This means the width (already computed earlier) in not an invariant, it may change, and in doing so pretty much everything else needs to be recomputed.  And if in turn any nodes hit (or stop hitting) their constraints, we may need to do it again and again.  Could we have an endless loop condition where the layout goes between two (or any other number of) possible states?

To summarize, snapping and fractional scale under certain circumstances (*) leads to:

- honoring constraints might be impossible
- moving a single node requires a new layout pass
- possible danger of infinite loop cycling between 2+ layout states

(*) the circumstances are: nodes having grow property set.

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

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