Circling back to a new layout algorithm

[Kevin Rushforth]

I think this will be a good improvement to implement to the JavaFX 
layout algorithm. I see that you filed JDK-8276671 [1] to track this 
enhancement.

As noted, the main concern will be making sure we don't break existing 
applications, so testing this will be key.

One other issue that will need to be addressed is what a good the 
threshold would be for the maximum number of iterations, such that if it 
doesn't converge we will stop anyway (and log a warning). This is a 
trade-off between performance and accuracy, although as noted in the JBS 
issue, if the layout doesn't converge it's a bug. The value we 
ultimately choose can be discussed during the review and testing. 
Regardless of what the threshold is, I recommend a system property 
(named something like "com.sun.javafx.scene.layout.threshold"). This 
will be helpful during testing.

What do other developers think? Would this be a useful problem to solve 
in layout?

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8276671


On 11/4/2021 7:31 PM, Michael Strauß wrote:
> I previously proposed a new iterative layout algorithm [1] that
> supports baseline alignment and introduces new APIs to give developers
> control over the way nodes are aligned. This is a solution to the
> long-standing problem that JavaFX cannot reliably lay out nodes that
> are aligned on their baseline [2]. The new layout algorithm might also
> fix some issues where the scene graph layout only settles after
> interacting with the controls (for example, by clicking).
>
> I've created a small application that shows the new APIs and a
> correctly working baseline-aligned layout [3]. In addition to that, I
> also built SceneBuilder with both the old and new layout system, and
> played around with it to find out whether there were any regressions
> or visual differences. So far, I haven't found any.
>
> In order to move this forward, I think it would be a good idea to test
> the latest version of the new layout system in more real-world JavaFX
> applications. Any help from JavaFX application developers is greatly
> appreciated. It's as easy as checking out the JavaFX sources from the
> PR [1], building a local SDK and linking your application with the
> binaries.
>
>
> Finally, here's a high-level overview of the new algorithm:
>
> When Parent::layout() is called on a layout root (i.e. a scene root or
> an unmanaged node), it will lay out its children in a loop until the
> scene graph under the layout root is fully laid out, which means it is
> clean and doesn't require further layout. The totality of layout
> activity for a single layout root is called "layout cycle". A layout
> cycle will often take a few layout passes to finish (but not more than
> 2 in most cases). There is no limit on how often Parent::layout() will
> iterate to lay out its children, so in principle, this could lead to
> an infinite layout loop.
>
> One source of infinite layout loops are incorrectly implemented controls:
>
>      class PathologicalControl extends Region {
>          final Text text = new Text("foo");
>
>          PathologicalControl() {
>              getChildren().add(text);
>          }
>
>          @Override
>          protected void layoutChildren() {
>              text.relocate(0, text.getLayoutY() + 10);
>          }
>      }
>
> In this example, each call to layoutChildren() moves down the text
> node another 10 pixels from where it was, which causes the layout
> algorithm to schedule yet another layout pass. It's an infinite loop.
>
> The layout system detects this by tracking how often a node
> invalidates the scene graph in a single layout cycle. If a node
> exceeds a threshold of 100 invalidations, it will be suspended from
> layout and can no longer invalidate the scene graph in the current
> layout cycle. A warning will be logged to notify developers of that
> fact.
>
>
> [1] https://github.com/openjdk/jfx/pull/433
> [2] https://bugs.openjdk.java.net/browse/JDK-8090261
> [3] https://github.com/mstr2/jfx-layout-sample