This is a bug in the splitter -- each splitter is bound to the window resize event, even if it has a parent splitter and is bound to its resize. The result is that each splitter triggers a resize when the window is resized, which accumulates in the resizes of the innermost one.
This has been fixed for the next internal build, so the number of layout changes will drop.
> Is there a problem with the splitter control that's causing it to fire this many times? I would expect a parent splitter (.references-wrap in my example) to receive all of the layoutChange events from children. I don't expect a child to have to listen to all of the layoutChanges above it.
It is the other way around. A nested splitter listens to the resize of its parent, because it may have to recalculate its size. The parent splitter does not care if the nested splitter is being resized, because it will use only its available space and not cause a change in its container size.
All the best,
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI