> On Nov 12, 2021, at 7:48 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > 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?
Sounds good to me. I’m all for it. > Would this be a useful problem to solve in layout? Absolutely. I have dialogs that have really irritating layout issues that magically correct themselves when you interact with the controls. Scott > > -- 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 >
