This is a new approach where a tree of slots is maintained. The elements are assigned to locked slots in this tree, except for the visible elements. These are temporarily assigned to the special visible-slot. This slot is inserted into the tree adjacent to a locked slot and all of its ancestors are unlocked. When we want to make a different set of elements visible, we reassign all the elements back to their "natural" locked slots, move the visible slot to the right place in the tree and assign the newly visible elements to it, unlocking all of it's current ancestors (and relocking it's previous ancestors). Because this assigns all of the visible elements to a single slot, it should avoid the problems of the previous tree approach, e.g. breaking margin-collapsing. However we can no longer rely on the layout engine to size the empty space above/below the visible content.
This is not a scroller, it's a proof-of-concept for benchmarking. It cannot handle updates and does not manage spacer divs above/below the unlocked content. It simply cycles through groups of elements, revealing chunks of 10 as fast as frame rate allows.
Particularly interesting are 3 things that seem unexpectedly slow. They all seem like O(n) effects that we should fix.
This is a new approach where a tree of slots is maintained. Each elements is assigned to 1 slot. When elements should be visible, all of their ancestors are unlocked. All other elements in the tree remain locked. We can no longer rely on the layout engine to size the empty space above/below the visible content.
This is not a scroller, it's a proof-of-concept for benchmarking. It cannot handle updates and does not manage spacer divs above/below the unlocked content. It simply cycles through groups of elements, revealing chunks of 10 as fast as frame rate allows.
It has quite slow setup due to O(n^2) effects in adding many slots (https://crbug.com/985652). Otherwise, it seems quite performant.
Style cost for custom-element is O(all children) when any slots change - https://crbug.com/971588
All except 20 elements are not assigned to any slot, 2 groups of 10 elements swap between the first and second slot. Style recalc and assignedNodes seem O(n) in the number of elements, not in the number of elements that have changed.
insertBefore is slow with slots - https://crbug.com/971930
SlotAssignment::FindHostChildBySlotName iterates over all children.