Virtualization comparison and use case

[Andrew-Hanlon]

Hi - this looks like a great effort to build a more performant and usable TreeView.

One thing I noticed in the demo application, is that the bound standard-TreeView has Virtualization explicitly turned off. After enabling it, the loading and memory usage are drastically improved such that the difference between the TreeView types is not as apparent.

In you experience, in what usage scenarios does the standard control fail?

[picrap]

Thanks for pointing this. I committed right now the change with virtualization enabled.

The standard control was not failing but I had big slowdowns on another application when expanding around 5000 items.

This VirtualTreeView improved performance on more complex TreeViewItems than the example shows. And it's actually the complex binding that was slowing it down.
The control is still in development, and I need to improve:

• Binding without creating item container in complex binding cases (to get the expanded state and children values).
• A sample with more complex items.

But since you ask, and I am curious, why are looking for an alternative to the default TreeView control?

[Andrew-Hanlon]

That's what I was thinking (more complex templates causing slower layout passes) and is one of the reasons I had for investigating TreeView alternatives.

The other main issues with the standard TreeView virtualization is the scrollbar thumb jumps and resizes since the control does not know the true size of nested branches.

Thanks