internally decides how many items to load while it is being measured. If you're using the default Recycling
virtualization, decreasing the size of the RadTreeView
should result in an initial load of a smaller number of items. Furthermore, in many scenarios a RadTreeView
with 20 items doesn't really cause any performance hit.
This is why I'm not sure why you're experiencing any performance issues. Can you please elaborate further on your RadTreeView
implementation. It would greatly help us if you can isolate the issue in a sample solution and send it through the ticketing system. Also, please describe the steps that reproduce the performance hit as well as the result you'd like to see instead. You can even capture a screencast as this will allow us to better understand the behavior of the control on your side. Specifically we'd like to know whether the performance hit is visible during RadTreeView
load, while expanding items or while scrolling.
Once we have more information regarding your scenario and its implementation, we will be able to further investigate the case and suggest a solution. Also, please note that RadTreeView
. You can use this feature to further optimize the performance of the control.