1) Pathological cases: So far, I haven't been able to produce pathological cases that exceed 3 layout passes by using standard layout containers and controls. If we need to have a threshold substantially higher than that depends on whether or not there are indeed legitimate cases where some kind of layout requires more passes to converge. Maybe we could log at a very fine level when a control takes more than 3 passes to converge, but still continue processing up to a substantially higher number of passes. This would allow developers to debug and optimize their custom controls, but still produce a valid solution if a particular control is generally stable, but just very poorly optimized.
2) I believe that the multi-pass layout algorithm shouldn't need additional documentation since it could be considered an implementation detail. There is no 1:1 correspondence between pulses and layout passes currently, and there won't be with the new algorithm. Also, any layout pass with the current algorithm can potentially trigger another layout pass, so that's not fundamentally different either. For control authors, we might need to document that it is generally okay to rely on circular dependencies between size hints, baseline offset and child nodes, as long as those dependencies allow the layout to settle. The fact that text nodes are preferred with respect to baseline computation is documented in Parent.getBaselineOffset(), maybe Node.getBaselineOffset() should also mention this. We might also add a section on baseline computation to the javafx.scene.layout package documentation, where I think it is most relevant (and currently entirely undocumented). 3) New API on Node: in order for this idea to work, there needs to be an abstract concept of "text node". Since the "baseline" concept is introduced on Node, I thought this would also be the appropriate place to introduce the "text node" concept; however, it could also be introduced on Parent instead. Note that the "text node" concept is introduced at a lower level than actual text controls like Labeled, because layout containers (which are not controls) need this information. Also, the definition of what constitutes "text" is left to control authors. In a very contrived example, a control might display an image, but declare itself to be "text". Am Fr., 19. März 2021 um 23:26 Uhr schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>: > > I'd be interested to hear from app developers on this list. > > Here are a few quick thoughts I have. > > As you note, this is a long-standing problem with layout in FX. You > mention in the performance considerations that for most cases this will > iterate quickly. It would be interesting to know what some of the corner > cases are, so we can see how bad the pathological case will be. I see > that you propose to iterate up to 100 times. Maybe a lower threshold > would be better? We already run layout passes 3 times in many cases. So > also running 3 (or maybe 4 or 5) times seems reasonable, especially when > your testing shows that most of the time it converges in <= 2 passes. So > a smaller threshold than 100 would seem to make sense. If a control > doesn't converge, you might consider logging it (in case an app > developer wants to debug it) perhaps at a "fine" level so it isn't shown > by default. > > How do you propose to document this behavioral change -- not so much the > fact that it will (usually) get the right answer now instead of the > wrong one, but more about the multi-pass nature of it, and the fact that > nodes with text will be "preferred". Related to that, how necessary is a > new public API on Node? > > -- Kevin >
