[API REVIEW] RT-30576 Parent : add new public layout method, optimized to only layout this parent and it's children.

[Richard Bair]

Thanks for the summary Jasper, I agree that we should look at this holistically.

I think the requestParentLayout() call is done when we don't know if the change in min/max/pref will result in an actual change in the size of the node, and therefore we don't know if it *needs* to relayout its children.

So for example, maybe the pref size has changed, but the node is in a StackPane, in which case its pref size changing doesn't actually matter because the size of the child is determined rather by the size of the parent.

I like both these names (requestParentLayout() and requestLocalLayout()). Both solutions seem important and sensible. Essentially what we're doing is making requestLayout() more fine-grained -- "I need to have layout() called, but this won't affect my parent in any way" and "I don't need my layout() called necessarily, but my size has changed in some way my parent should be informed about".

Richard

On May 28, 2013, at 9:16 AM, Jasper Potts <jasper.potts at oracle.com> wrote:

> Hi All,
> 
> Seems like we have 3 use cases:
> 
> requestLayout()                 - my layout and/or my size has changed - action relayout myself and all parents
> requestParentLayout()     - my size has changed only - layout my parents
> requestLocalLayout()       - something requiring my children to be relayed out has happened but there is no change in my pref size - just mark this node dirty for layout next pulse
> 
> 3) is a optimization for preventing excessive layout that makes sense.
> 2) I am not sure when this can happen. When can a region's size change without is children needing to be laid out? Or have I miss understood what it does?
> 
> Seems like we should look at all these extensions to layout API as one.
> 
> Jasper
> 
> 
> On May 22, 2013, at 8:15 AM, mick.fleming <mick.fleming at oracle.com> wrote:
> 
>> 
>> Hi Martin,
>> 
>>> I would like to introduce similar call, see 
>> 
>> it's a shame about the overlap, but at least I
>> assume it means that we're in agreement that
>> something can be done here :-)
>> 
>> There does seem to be a a difference between the
>> two. While your requestParentLayout doesn't clear
>> the size cache, it does go up the hierarchy.
>> My proposal is for a method that specifically
>> doesn't request a layout up the hierarchy, and
>> only sets the current Parent as dirty. There are
>> cases where it's know that the change is only local.
>> My change is aimed primarily at Controls and the like,
>> for cases where they've changed their internals, and it's
>> known that there is no knock-on effect.
>> 
>> I have an implementation, that includes changes to
>> Controls, Charts and Layout to utilize it.
>> 
>> 
>> regards,
>> mick
>> 
>