Is it possible to get a node layout relative to the root node?

[UditDey]

Hi I have a question about using this library, in my application I need random access to any node's layout relative to a root node. It seems that the TaffyTree::layout() method only gives you the layout relative to the parent node. Is it possible to do a second pass to resolve all layouts relative to a root node or something like that? Will I have to roll my own tree using the low level API to do this?

Thanks

[nicoburns]

Hi! Taffy doesn't currently provide the layout relative to the root node. You have to calculate this by recursing down the tree from the root. If you need random access then you could do this as a pass over the whole tree and store the result for each node.

If you want Taffy to provide this out of the box then we could turn this issue into a feature request for this feature. It would be pretty trivial to add, there's just a memory usage cost every time we store more information on each node.

[UditDey]

I've just finished writing a custom tree impl that does what I want. It's almost identical to TaffyTree but I've added another pass in compute_layout() where it recursively goes through each node and adjusts its layout position relative to its parent, so that at the end every node is relative to the root. I reused the final_layout field instead of storing it in a new one, so this doesn't take any extra memory. This did however require an extra dirty flag per node.

I think this would be a useful feature so yeah I'd like to turn this into a feature request. My suggestion would be to provide this as an option, so you either get layouts relative to the parent, or relative to the root, but not both. This should allow you to reuse the layout field if memory usage is a concern. Plus I doubt users would need both kinds of layouts at once anyways.

I haven't looked into it yet, but I think rounding and this uhh lets call it "root node adjustment" can be done in the same pass, so that should help reduce perf costs as well.

[coderedart]

This feature might require careful consideration. Anytime a parent node moves, then all its descendant nodes must update their relative_pos_to_root data. This can be expensive in certain cases.

Scrolling areas or lists

Usually have a lot of children. If the scrolling area (or any of its ancestors) moves or zooms in/out, all its children will need to update their locations.

Animations

when a bunch of children in a grid are moving due to animations. eg: Imagine if each image was a node with its own children.

FlexBox (Column/Row)

If you remove the first (left or top) widget (like deleting a contact at top or removing a song from a queue or notifications disappearing after a timeout), the rest will move to fill the empty first slot.

[nicoburns]

Anytime a parent node moves, then all its descendant nodes must update their relative_pos_to_root data. This can be expensive in certain cases.

Ultimately the absolute coordinates need to be resolved somewhere. I wouldn't expect it to be particularly expensive to do this in Taffy. It would just be done as a post-pass though. So there's also no real need for it to be in Taffy.

[SkyLeite]

This would be great, honestly. I'd much rather the tree calculate this so my implementation can focus on drawing the widgets on screen.