Idea for sizing of parent Nodes to contain all children

What if we do something where whenever we set size and position of a Node, that action is communicated to that Node’s parent.

A Node that receives these messages from its children can (if an option is turned on) keep track of which child Node is furthest to the left, furthest to the right, furthest up, furthest down, furthest forward, and furthest backward. Based on that info the parent Node can (if said option is enabled) automatically size itself so that it contains all of it’s children. Children send messages on size and position change. When the option is toggled on a parent, all children are notified; if the option on a parent is turned off, then children don’t send messages, otherwise they do (that’d be more performant than if children were to always send messages and let the parents decide whether or not to care).

In theory, a size change on a child node could propagate all the way up the scene graph to the root, stopping where the automatic sizing option is turned off.

The effect would be similar to this traditional DOM example:

The parent DIV in that example is sized to contain its children, but there are some problems with that. For example, now let’s reposition child 2:

You’ll notice now that the parent doesn’t fully contain its children. You might try setting the children to position absolute, but that doesn’t work at all:

There isn’t really a way to do this with regular HTML+CSS; it requires setting the size of the parent container manually which means we need to do some calculations. Who knows, there might be a way to do this with the newer flex-box API, but I don’t care much about it because the API is needlessly complex when it doesn’t need to be. It’s tedious to use flex-box.

So, this got me thinking about how we can “do some calculations” ourselves and make it easy for the users of our library to benefit from it; so that setting a single option to true is just as easy as setting a single (non-existent) CSS property would be.

Any thoughts on the best way to do this?

1 Like

Don’t forget to start at the bottom of the tree branch. A two pass calculation would be needed.

Lot to think about here for sure! :stuck_out_tongue: .

Sizing is tricky without all the extra options.

Yes indeed it is! Especially the way it is in CSS, which is horrible! :laughing:

I think it can just start whenever a node is added and has it’s initial sizing and positioning, or whenever ever those things change. So, it’s possible that the change might happen mid-branch, not near a leaf, and it would propagate from there upwards (no need to worry about the children if they haven’t changed).

I started organizing my top level API, which will be at (but I haven’t pushed yet, that’s @andrewreedy’s prototype there for now). :smiley:

Hi All,

I would like to promote the usefulness of this idea.

If one does this, then they get access to a nifty data structure that is essentially an R-tree, and enables efficiently calculating things like:

  • collision detection of nodes (without the need for a physics engine)
  • given a screen X & Y, one can work out all the currently intersecting nodes (thus enabling some very snazzy gestures that are beyond typical browser capabilities)
  • only update nodes that are inside the view frustum

I think it would also make the API simpler.

(Q, does the current Famous API have this data available in some form?)


1 Like