Производительность Silverlight с большим количеством объектов Org Chart

Question

Я работаю над проектом схемы диаграммы (SL 3), и я вижу, что поток пользовательского интерфейса зависает, когда диаграмма строит около 2000 узлов и когда она делает это мин, а затем FPS упасть до обхода.

Вот код потока. Page.xaml.cs вызывает службу wcf, которая возвращает список пользователей AD. Затем мы используем Linq для сборки набора узлов для привязки к Orgchart.cs

OrgChart.cs - это холст и отображает коллекцию узлов и соединительных линий.

Node.cs - это холст, и пользовательские данные могут содержать дочерние узлы.

NodeContent.xaml - это элемент управления пользователя, который имеет границы, поэтому я могу установить фон, текстовые блоки для отображения данных пользователя, события, которые обрабатывают выбранные и расширенные узлы, и раскадровки, которые изменяют размер узлов при их выборе или расширении. замеченный в часы отладки, здесь, в InitializeComponent(); где он загружает xaml, похоже, где происходит прецедент.

System.Windows.Application.LoadComponent (это новый System.Uri ("/ Silverlight.Custom; component/NodeContent.xaml", System.UriKind.Relative));

Итак, у меня есть два вопроса.

1. Может ли резьбовая помощь каким-либо образом с зависанием нитей UI при рисовании узлов?
2. Как я могу избежать удара при вызове этого пользовательского элемента управления?

Любые советы или рекомендации, которые кто-либо может предоставить, будут очень признательны.

Спасибо, KC

Answer 1

Насколько делать что-либо с резьбой UI будет не добьются. Возможно, вы сможете массировать данные по фоновым потокам, но если вы общаетесь с любыми объектами, которые привязаны к интерфейсу в фоновом потоке, вы ищете проблемы. Вам действительно нужно разделить эту работу с пользовательским интерфейсом, а затем вызвать ее обратно.

Я предполагаю, что Siverlight просто занимает некоторое время, чтобы нарисовать все узлы. У нас есть приложение, которое привлекает около 100 довольно богатых виджетов. На хосте ItemsControl видны только около 20 или 30 виджетов. Мы достигли лучшей производительности, используя панель виртуализации, которая фактически не создает элементы скрытого пользовательского интерфейса до тех пор, пока они не понадобятся. Здесь есть некоторые компромиссы, и мы все еще работаем над проблемой, но страница загружает намного быстрее. Вы можете использовать аналогичную стратегию для рисования своих узлов, только загружая узлы, которые должны быть видимыми. Кроме того, вы можете загружать части дерева на поверхность рисования кусками. Возможно, возьмите первые 100 записей и нарисуйте их, затем нарисуйте следующие 100 и т. Д.

Answer 2

Звучит так же, как ваш пользовательский интерфейс имеет естественную точку для сравнения нагрузки, загружая UI для узлов по требованию.

У вас есть узлы, которые можно развернуть и свернуть. Загружайте пользовательский интерфейс только для расширенных узлов. Когда пользователь расширяет узел, затем загружает пользовательский интерфейс для своих дочерних узлов в этой точке.