More fine grained dirty marking #425

New Issue

2017-02-22T03:56:17-08:00

emilsjolander commented

2017-02-22 03:56:17 -08:00

(Migrated from github.com)

Currently a node's dirty flag propagates to the root of the tree ensuring that when any node is invalidated its whole subtree will be re-calculated. This is often times not needed. There are many properties which only effects a node's children and would not need to propagate all the way to the root such as align-items. Also in cases where the style does change layout it may not need to propagate all the way to the root but can often stop at the nearest position: absolute parent.

This change has the potential of greatly improving performance of re-calculating a tree.

This might require adding a second dirty flag named hasDirtyChildren ensuring that traversal still works even though a parent is not marked as dirty.

Currently a node's dirty flag propagates to the root of the tree ensuring that when any node is invalidated its whole subtree will be re-calculated. This is often times not needed. There are many properties which only effects a node's children and would not need to propagate all the way to the root such as `align-items`. Also in cases where the style does change layout it may not need to propagate all the way to the root but can often stop at the nearest `position: absolute` parent. This change has the potential of greatly improving performance of re-calculating a tree. This might require adding a second dirty flag named `hasDirtyChildren` ensuring that traversal still works even though a parent is not marked as dirty.

arcanis commented

2017-02-22 06:18:56 -08:00

(Migrated from github.com)

I've worked on something similar for mylittledom; at first I tried to only traverse children that were marked as dirty, but the issue was that a dirty node would possibly not only affect its children, but also its siblings (except when absolutely positioned, but it's often not the case, so the optimization would not affect the hot path and would probably make it slower). The algorithm I went with is to always cascade the layout on both dirty nodes and on any children of a node that has at least one dirty children, but to stop the cascading if such a node (which isn't explicitely marked as dirty) does not change its layout.

My implementation is here if you want to give it a look: https://github.com/manaflair/mylittledom/blob/master/sources/core/dom/Element.js#L776-L842

I've worked on something similar for mylittledom; at first I tried to only traverse children that were marked as dirty, but the issue was that a dirty node would possibly not only affect its children, but also its siblings (except when absolutely positioned, but it's often not the case, so the optimization would not affect the hot path and would probably make it slower). The algorithm I went with is to always cascade the layout on both dirty nodes and on any children of a node that has at least one dirty children, but to stop the cascading if such a node (which isn't explicitely marked as dirty) does not change its layout. My implementation is here if you want to give it a look: https://github.com/manaflair/mylittledom/blob/master/sources/core/dom/Element.js#L776-L842

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#425