In my app I create panels dynamically to display a 2-level tree structure. It's about 30 nodes at the top level and about 600 nodes underneath. There are two problems with this:

a) The whole process of building a tree takes a long time. What can be done to speed it up?

b) The second problem is that these panels with nodes must be initially collapsed, but despite I call Minimize method and their internal state corresponds to the minimized view, they actually are not minimized when displayed. Moreover, this behavior is manifested only if the AutoSize.Height property of a panel is True. In real app their behavior even weirder, but in the attached demo it apparently depends on AutoSize.Height only. Is this some kind of RTL error or I have mistaken somewhere?

ooptimum wrote:

<< In my app I create panels dynamically to display a 2-level tree structure. It's about 30 nodes at the top level and about 600 nodes underneath. There are two problems with this:

a) The whole process of building a tree takes a long time. What can be done to speed it up? >>

In terms of the speed question, are you using BeginUpdate / EndUpdate?

Yes, I use these methods, as well as some other little tricks. I would appreciate if you will try to improve code  attached to my first message in this thread.

Mark Brooks wrote:

In terms of the speed question, are you using BeginUpdate / EndUpdate?

ooptimum wrote:

> In my app I create panels dynamically to display a 2-level tree structure. It's about 30 nodes at the top level and about 600 nodes underneath. There are two problems with this:
>
> a) The whole process of building a tree takes a long time. What can be done to speed it up?

The simple answer is that you just don't create them, but you use a virtual arrangement instead. That is, create only what is needed to fill the display, and add code to tell them to update the displayed information according to an object they are told to display. You will find it all gets a lot more sensible, if a tad complicated.

I made a tree display that used this, and it worked just fine, including collapsing nodes etc. The code is posted here, but IIRC is slightly incomplete, and I don't recommend it really as it is complex. You are better off with a custom fit for your purpose.


--

Matthew Jones

"Matthew Jones" wrote:

> The simple answer is that you just don't create them, but you use a virtual arrangement instead. That is, create only what is needed to fill the display

I agree that redesign is an approach proven to work. However, in this case we have determined amount of data to display, which hardly will change, and all should be presented to user at once. In fact, this particular design is also proven to work very well in terms of UX in other app. The question is whether there is some room for improvement in speed or not.

ooptimum wrote:

> > The simple answer is that you just don't create them, but you use a virtual arrangement instead. That is, create only what is needed to fill the display
>
> I agree that redesign is an approach proven to work. However, in this case we have determined amount of data to display, which hardly will change, and all should be presented to user at once. In fact, this particular design is also proven to work very well in terms of UX in other app. The question is whether there is some room for improvement in speed or not.

You misunderstand. I don't say redesign, I say make it virtual. It is the only way to improve the speed, and it is proven good. The DOM management is not something that you can improve on. I faced this in a big project, and everywhere I ran up against making lots of items, the answer for performance is virtualising.

--

Matthew Jones

Matthew Jones wrote:

> I don't say redesign, I say make it virtual

Hmm, thinking further, maybe that is a redesign. Not visually, but implementation. It is still the answer though...

--

Matthew Jones

"Matthew Jones" wrote:

<<I say make it virtual. It is the only way to improve the speed, and it is proven good. The DOM management is not something that you can improve on. I faced this in a big project, and everywhere I ran up against making lots of items, the answer for performance is virtualising.>>

I concur with this statement. Certainly once you get into multiple hundreds of panels then I struggled to get acceptable performance without some form of virtualisation. It is a combination of DOM performance and, I think, EWB layout control. Whilst I LOVE the layout capabilities and would NEVER wish to do without them, I think there is a performance penalty to pay compared with, say, Angular.

"Matthew Jones" wrote:

<< Hmm, thinking further, maybe that is a redesign. Not visually, but implementation. >>

That's what I actually meant, not a visual appearance.

As to UI virtualization, I understand the general concept of it, but so far I can’t think how I could use it in this case.

Look, I need to create something like a two-level directory, where at the top level there will be categories of, say, questions, and at the second level the questions themselves. Categories and questions can be filtered, so that part of the panels and checkboxes will be simply hidden. However, without filters, all categories and questions should be visible. And I yet do not understand how virtualization can help here.

Mark Brooks wrote:

<< I concur with this statement. Certainly once you get into multiple hundreds of panels then I struggled to get acceptable performance without some form of virtualisation >>

I have already answered Matthew above, but since you insist on virtualization, tell me, please, how you can apply it here. Imagine that we have a very long checklist of about 600 questions, of which a user should select, say, only three. Questions are distributed among 30 categories approximately equally. They can be filtered, but without a filter we have to show them all. How this can be virtualized?