[External] : Re: Consistent baseline layout algorithm

[Kevin Rushforth]

Circling back to this: Do any JavaFX application developers on this list 
have any thoughts? I think this is a good idea, and it seems worth 
moving this forward, but it will require a fair bit of effort. I'd like 
to hear buy-in from other developers -- particularly those who develop 
or use custom controls.

A few additional comments:

* Regarding the threshold, I like the idea of logging at a fine (or 
finer) level if it goes beyond a smaller number, say 3 or 4, passes, but 
continuing further to iterate. I wonder if 100 might be too large for 
the default limit, though. It seems likely that the control is unstable 
and will never converge if it gets to that many layout passes. If there 
were a way to analyze what a reasonable limit is that would be better 
(if not, we can probably live with a fairly high value, if it really is 
an unlikely pathological case). Assuming a reasonably high threshold, 
logging at a warning level would be good if it doesn't converge.

* Documentation: I do think we will want to document the overall concept 
of layout needing multiple passes to converge in some cases, along with 
documenting the threshold. I also think that Node::getBaselineOffset 
should mention the preference of text nodes. The concept of "text" nodes 
needs to be on Node, if for no other reason than that Text doesn't 
inherit from Parent.

* This will need to be very well tested, both to ensure no regressions 
in behavior, and with many new tests added to validate the new 
functionality, including testing the threshold logic.

-- Kevin


On 3/20/2021 6:42 AM, Michael Strauß wrote:
> 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.rushforth at 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
>>