TreeView Performance with bound data

[Glockbert]

I have a large set of hierarchical data, too much to display at once, so I allow the user to page thru it. I have been working on UI perf and have hit a snag with ListView.

Currently the data is bound to an observable collection of a Class which also implements INotifyPropertyChanged to allow updates of some data in the class to update the control UI. The user can page thru the large collection of data. Next/Prev buttons get new results that re-populate the ListView by updating the viewable collection. It all works well., except for UI flickering in TreeView.

Worth mentioning, the data set can also be viewed in other ways, so the tree view can be replaced with a ListView that binds to the same collection in the same way. I mention this because I am not having the same issues in the ListView control on the same data set and binding model.

So the problem: When updating the TreeView with new data, I am getting odd update behaviors. The tree is first rendered with some nodes in the unexpanded state (they are set to IsExpanded, verified). It's just for a few frames, then you can see the chevrons change and the data get drawn. It's ugly and unprofessional looking. It looks like a simple flickering update bug at first, but in reality (recorded and stepped thru the frames) it's doing multiple UI updates that don't reflect the state of the nodes.

As a test, I turned off the databinding and just manually populated the tree with basic string data, and the problem goes away. It's fast, and snappy and no flickering.

At first I thought it was some sort of transition animation happening, but I have those set to x:Null, and they have no effect on or off in the un-bound test case.

Is this just a bug in TreeView? Is Data Binding perf so slow the render UI is getting ahead of the binding process and causing these intermediate states to get rendered while it's populating the tree? I don't think it is data binding or render perf, because the ListView version bound to the same data set uses more bindings and a more complex Grid for the DataTemplate than the TreeView and it performs fine, as I stated earlier.

I would just manually build the TreeView without databinding as I did in the test, but it seems they went out of their way to make it difficult, possibly impossible, to use more than a string for TreeViewNode.Content and have it display. Another thing ListView does fine, but doesn't work in ListView. So frustrating.

I've searched and can't find a mention of this specifically. Maybe I'm missing something. Suggestions welcome.

Thanks!
 

[llothar]

This might be a bug but all I can advise is to never use data binding on complex/large data. Not in windows or Apple. It is known to be very slow. And don’t start to go declarative with SwiftUI or jetpack compose in this cases. It becomes insane slow for little benefits.

[Glockbert]

Thanks for the reply. I thought it was related to data binding, and tried to do it manually, just could never figure out how to make that work in this control (another bug IMO). Unlike ListView, you can't assign complex UI elements to item content and have it render, the methods around that all lead you back to data-binding. But it turns out it has to be a bug in TreeView and not data binding or render performance. Here is how I know:

About an hour after this post, I just got sick of messing with it, and decided to try something. I wrote my own "FakeTreeView" using a ListView object.

Took about an hour and only about 20 lines of C#. Just flattened the hierarchical collection to a list, added depth, indented using an empty column, setting its width to a bound value based on depth. Wrote a custom "chevron" control that acts like a simple button, flips the chevron visually, and triggers an event allow me to change "children" items to be visible or not when expanded or not. Stuck the chevron control into my item grid after the indent. Only visible on non-leaf nodes.

The result is something that is visually identical to TreeView, same functionality as before, but is very fast, and displays as it should. I can flip thru the dataset (500 to 1000 items per "page") without flicker as fast as I can click the mouse button. So data binding perf isn't the issue. It's just that TreeView is non-performant and buggy.

Thinking of repackaging "FakeTreeView" as a custom control and putting it out for others, maybe it will embarrass WinUI team to fix the TreeView bugs.

I'm developing a love/hate relationship with WinUI 3. It seems you have to follow a very narrow path of the few simple cases they "tested", if you stray into other use scenarios you have to deal a lot of bugs. Honestly, from my experiences so far, it's not really production ready. Just my opinion.