Производительность 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. Может ли многопоточность помочь каким-либо образом при зависании потока пользовательского интерфейса при рисовании узлов?
2. Как я могу избежать попадания при вызове этого пользовательского элемента управления?

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

Спасибо, KC

Answer 1

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

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

Answer 2

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

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