Re: Layouting in Clutter 2.0

[Lionel Landwerlin <llandwerlin gmail com>]

Hi Neil,

I'm glad I'm not the only one thinking about this. Some comments below :

On 25/10/12 12:22, Neil Roberts wrote:
> Hi
>
> As development is starting for Clutter 2 and we have a chance to break
> API, I think it would be good to think about whether it would be worth
> making any changes to the layouting mechanism.
> ...
>
> Queuing a relayout will be changed so that it doesn't bubble up the
> hierarchy and queue a relayout on every ancestor. The âneeds_allocationâ
> flag will be removed. Instead, the stage will maintain a list of actors
> that need relayouting. Just before painting, the stage will keep pulling
> off the head of this list and calling âallocateâ on that actor until the
> list becomes empty. We might want to rename âallocateâ to âlayoutâ or
> something to avoid confusing it with set_allocation. It should be
> supported and expected that actors can queue a relayout and add
> themselves to the list during the allocation cycle.

So basically the implementation of queue_relayout would be modified
to take a extra argument telling which one of your child has queued
a relayout (pretty much like queue_draw() today) and could be rewritten
as a simple test :

Are you a container who cares about its children size?
1) Yes => call queue_relayout() on your parent
2) No => add the actor that called your queue_relayout() function to the 
stage's layouting queue

> The list will be kept sorted in increasing order of the depth of the
> actor. That way, the relayout callbacks for an actor's parent will
> always be called before the actor's own relayout callback. This should
> ensure that by the time the actor lays out its children it will have its
> final size.
> ...
>
> Why would want to make this change?
>
> â People seem to often encounter problems with the old system where they
>    would accidentally queue a relayout during the allocation cycle. This
>    ends up with awkward to solve bugs.

Yes, I've seen a few g_idle_add() to workaround allocation issues.
Also until Clutter 1.8 which removed a warning (only visible when
compiled in debug) in queue_relayout(), it was nearly impossible
to implement an infinite scrolling container. The modifications
you're proposing would surely help with that, to avoid dirty trick
like overriding the queue_relayout vfunc to prevent these warnings.

> â We've had a fair few problems keeping track of the âneed_allocationâ
>    flag. This is particularly problematic if containers do not allocate
>    their children for whatever reason because then the flag will end up
>    in an inconsistent state. This can prevent the allocation from
>    bubbling up if the broken actor later again needs a relayout.
>
> â The new model lets us optimise certain types of containers. For
>    example, a container that is displaying a split pane with two actors
>    might not care what the preferred size of the children are. In that
>    case if one of the child panes needs a relayout, it doesn't need to
>    involve the container or any of the ancestors.

This would certainly optimize usual cases where a small bit of text
changing deep in the scene graph's tree triggers a relayout on
massive amount of actors above him even though the parent of
the text actor is going to allocate him at the exact same size.

> â It makes it easier for example to implement scroll-view containers
>    that don't want to bother allocating children that are not visible.

Or infinite scrolling container that reuses children from a pool as
it's allocating them. This triggers relayouts within the allocation cycle.

> I'd be happy to help with a patch for something like this model if we
> can agree on a plan.

Hope we do.

-Lionel