Hi all,
I use .NET 1.1, NedAdvantage 2007.1
I have to load 6000 nodes into an ultrawintree, deepest level is 4. All nodes were added using the AddRange method except the first node. Icons are assigned to the node by means of an index from the imagelist. When i call the BringIntoView method after filling the tree, it could take up to 6 seconds before the method completes. When i do not set an image index, the BringIntoView method terminates immediately.
Has anyone experienced this and how do i get arround this problem?
Regards
Peter
That doesn't sound right, so you should probably report it as a bug.
Brian,
Yes, this does solve the performance issue with scrolling thru the three, but i still see a significant slow down in loading performance of the tree when i load without images.
If i load the three without images, it is at least 30% faster for a tree of 3500 nodes. One might expect a bit of slow down for the graphical eye candy, but 30% is just to much.
Anyway, many thanks for your help
Best Regards
Instead of assigning the image's index to the Appearance.Image property, assign ImageList.Images[index] to it.
You are right that scrolling is slugish also, however what BringIntoView is concerned, this methods also slows down when i don't use images at all, so this seams to be a secondary problem.
You speak about setting it to a reference, do you mean that i should load the icon dynamically and then set the image property? Do you have some sample code for that? I would appreciate it.
I do think infragistics should put a warning into the documentation, that using an imageindex for the treeview downgrades performance for large treeviews and that it would be better to use an image reference (and how to do that)
I vaguely remember an issue with the .NET ImageList whereby performance was impacted adversely because something caused the collection's IndexOf method to be called frequently; IndexOf causes a linear search through the collection, which can hit performance significantly. I think the .NET TreeView got around this using some internal code that we of course don't have access to.
If this is the same issue, the solution is to simply not use the image's index, but rather assign a reference to the image. Also, this had nothing to do with BringIntoView, it was caused by the fact that when we regenerate the UIElements for the control, we have to get a reference to the image in order to draw it. You could verify this by commenting out the call to BringIntoView; even when scrolling the nodes, you should see sluggish performance. If there is any doubt, just log an incident with Developer Support and we will sort it out.