Производительность WPF для большого количества элементов на экране

Question

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

Я запускал инструменты WPF Performance Suite в приложении, когда на экране имеется большое количество этих элементов управления (т. Е. Когда пользователь уменьшил масштаб), FPS падает до 15, что не очень хорошо.

Вот основная схема XAML:

<Window>
  <Window.Resources>
    <ControlTemplate x:Key="LandTemplate" TargetType="{x:Type local:LandControl}">
        <Canvas>
            <Path Fill="White" Stretch="Fill" Stroke="Black" StrokeThickness="1" Width="55.5" Height="74.687" Data="M0.5,0.5 L55,0.5 L55,74.187 L0.5,74.187 z"/>
            <Canvas x:Name="DetailLevelCanvas" Width="24.5" Height="21" Canvas.Left="15.306" Canvas.Top="23.972">
                <TextBlock Width="21" Height="14" Text="712" TextWrapping="Wrap" Foreground="Black"/>
                <TextBlock Width="17.5" Height="7" Canvas.Left="7" Canvas.Top="14" Text="614m2" TextWrapping="Wrap" FontSize="5.333" Foreground="Black"/>
            </Canvas>
        </Canvas>
    </ControlTemplate>
  </Window.Resources>

  ...
  <local:LandControl Width="55.5" Height="74.552" Canvas.Top="xxx" Template=" {StaticResource LandTemplate}" RenderTransformOrigin="0.5,0.5" Canvas.Left="xxx">
  <local:LandControl Width="55.5" Height="74.552" Canvas.Top="xxx" Template=" {StaticResource LandTemplate}" RenderTransformOrigin="0.5,0.5" Canvas.Left="xxx">
  <local:LandControl Width="55.5" Height="74.552" Canvas.Top="xxx" Template=" {StaticResource LandTemplate}" RenderTransformOrigin="0.5,0.5" Canvas.Left="xxx">
  <local:LandControl Width="55.5" Height="74.552" Canvas.Top="xxx" Template=" {StaticResource LandTemplate}" RenderTransformOrigin="0.5,0.5" Canvas.Left="xxx">
  ... and so on...
</Window>

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

Я видел другие ТАК вопросы по этому поводу, и люди говорили, что я могу рисовать на заказ, но я действительно не понимаю, как это имеет смысл, когда вам приходится масштабировать и перемещать, как я.

Если кто-нибудь может помочь здесь, это было бы здорово!

Mark

Answer 1

Это может звучать банально, но - Бесплатного ланча нет.

Я работал над этим в течение последних двух лет. Этот продукт состоит из 4 браузеров, чьи интерфейсы в основном ZUI. Все, кроме Атласа, используют визуальные эффекты для своего графического рендеринга, и было получено много уроков и несколько недостатков.

1) FrameworkElements не ваш друг. Движок FE на современной карте GFX и ЦП максимально разгоняется до 500-600 элементов, но это зависит от их сложности. FE примерно в 10 раз тяжелее визуальных.

2) Текст значительно повлияет на частоту кадров. Кривые рендеринга дорогие См. Пост Робби Ингебретсена для подсказок по использованию анимированного текста

3) Отбор важен, но добавление / удаление из VisualTree стоит дорого . Свертывание / сокрытие - это своего рода компромисс.

4) В WPF 3.5 у вас есть 2 варианта: запрограммировать до уровня Visuals или использовать что-то вроде Planerator , затем манипулировать камерой для панорамирования и масштабирования, но это требует от ваших пользователей хорошей карты gfx.

5) В WPF 4.0 дела обстоят намного лучше из-за того, что называется Cached Composition . Это работает по той же причине, по которой работает Planerator. Карта GFX отображает ваши элементы управления в растровое изображение и масштабирует растровое изображение.

Использовать это в 4,0 просто - настройка .CacheMode для ваших самых дорогих FrameworkElements, и все станет намного быстрее. Вы также можете управлять сглаживанием текста и масштабами восстановления растровых изображений (EnableClearType и RenderAtScale)

.

В моем браузере Atlas я мог отображать более 700 фрагментов текста + простые прямоугольники, не теряя интерактивности панорамирования и масштабирования. До 4-х карта была непригодна для использования.

Улучшение интерактивных характеристик требует времени, целей и измерений. Удачи.

Kael Rowan имеет превосходную серию статей о ZoomableCanvas, над которым он работает. Он использует Quadtree и PriorityQueue для реализации и позволит вам реализовать семантическое увеличение.

Обновление: 8-07-10 Добавлены текстовые подсказки и ссылки ZoomableCanvas

Answer 2

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

Обзор преобразований
Как: масштабировать объект
Как перевести элемент