Производительность 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> 

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

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

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

Марк

Answer 1

Это может показаться банальным, но - Там нет никакого свободного обеда.

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

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

2) Текст значительно повлияет на вашу частоту кадров. Визуализация кривые дорого См Robby Ingebretsens post подсказки на использование анимированного текста

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 для реализации и позволит вам реализовать семантический зум.

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

Answer 2

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

Transforms Overview
How to: Scale an Object
How to: Translate an Element