TreeGridView scroll performance


I have a TreeGrid with over 600,000 items.
At startup, scrolling performance is good, but when I add a subitem the performance decreases depending on the location of the parent item.

Anyone know why and how I can fix this?


In this GIF, only parent items are loaded and children are loaded on demand when the parent is expanded

Before asking this question, I suspected my code, after a scan of the application, 95% of the processors it uses by “native code” and I don’t know if this is from Eto or WPF



I know more. @curtisw sorry to call you directly, but even though this issue is from WPF, the ETO library can fix it.

This only happens when an item is extended or collapsed and a row is selected in the grid.
except the first time.

I solve it with:

ReloadItem (item, reloadChildren: false);
ReloadItem (item);


For this test, the double-click event is:

void OnDoubleClick (object sender, GridCellMouseEventArgs e)
     var item = e.Item as TreeGridItem;
     if (item == null) return;

     item.Expanded = !item.Expanded;
     if (item.Expanded && item.Children.Count == 0) {
          item.Children.Add (new TreeGridItem (-1, "test", "any", "..."));

     ReloadItem (item, reloadChildren: false);
     ReloadItem (item);

And the same test with CellFormatting actived:


The problem persists if I use the arrow on the left side (because I can’t deactivate the selection before).
Is there a way to capture its event or hide it?

Thank you, jmv

Hi @kitjmv,

Thanks for reporting the issue! I’ve created RH-61932 to take a look at fixing that.

1 Like

Have you ever opened a file with 600k entries in Notepad++? It’s not the fastest as well. I’m pretty sure WPF does a lot of optimisations but if it conditional needs to render, then its likely you disable internal performance optimisations. How should Eto makes this better?
The question I would ask myself is what is the point to expose the user to so many items? What if a user needs to pick entry 312462 ? You should add some sort of filter/searchbar or you group entries based on the type or by a range of indices.

While I agree on this point, Eto actually uses WPF’s DataGrid control for the TreeGridView, and manages the tree rendering and expand/collapse data itself, as there is no built-in multi-column tree control in WPF or WinForms.

So, there may be something that can be done to speed this up if the fault lies in Eto’s code. In particular, since it’s fast when there is no selection there may just be some extra processing it is doing that should theoretically not be needed in that case. It could also improve performance for smaller data sets, which I am always interested in.

That being said, if it is indeed just something within WPF that is slowing this down, there may very well not be anything we can do to fix it.


Note that today everything is working fine. I had to effectively remove any preselection and emulate it with row formatting.

Moreover, there is no interest for the user, it is a debugging control.
The user interface is simpler, but since all this user interface is in Eto it is easier for me to write the controls hidden to the user with the same library. Especially since they are “hidden” but included in the global window

Cool, thanks for letting me know. I’ll keep the issue open as I do want to track down why it is slow in that case, eventually.