WPF Performance. Неправильный расчет грязных прямых

Question

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

Проблема в том, что приложение работает очень медленно/вяло. Особенно обработка таблиц данных (прокрутка, сортировка, выбор) происходит крайне медленно и делает приложение непригодным для использования.

Я проанализировал состояние системы, когда одна вкладка, содержащая несколько текстовых полей, выпадающих списков и меток, открывается и остается бездействующей (ожидая ввода пользователя).

Это мои выводы:

• Все рендеринга рассчитывается на GPU
• Там нет производительности тяжелых функций, таких как анимация, растровые эффекты, прозрачность и т.д.
• Когда вкладка (только курсор мигает в сфокусированном текстовом поле, остальная часть вкладки статична и даже не содержит каких-либо данных), графический процессор работает до 90%
• GPU падает до 0, когда вкладка теряет фокус.
• Процент GPU напрямую зависит от размера окна. Небольшое окно доводит его до нескольких процентов, полный экран приближается к почти 100%
• WPF Perforator сообщает мне, что WPF вычисляет грязную область для всего вклада, а не только мерцающий курсор
• Отчеты WPF Perforator грязные скорости обновления прямоугольник больше, чем 20/с на вкладке ожидания, и они непосредственно коррелируют с использованием GPU

Мой вывод: в процессе разработки много пользовательского кода (макет, обработку событий и т.д ..) был введен чтобы соответствовать WPF для архитектуры, основанной на бэкэнд системы в целом. Я предполагаю, что из-за того, что какой-то пользовательский код был испорчен механизм WPF. Это приводит к слишком большому объему рисования и, следовательно, к очень высокому использованию графического процессора. Эти необходимые действия приводят к проблемам, описанным выше.

Теперь я ищу любой совет, где я должен начать свое расследование. Или, другими словами: каковы типичные ошибки, которые может сделать разработчик для того, чтобы разбить алгоритм обновления Flash WPF. Любой вход высоко оценен.

Большое спасибо и с наилучшими пожеланиями!

Manuel

Answer 1

Спасибо за ввод. Позвольте мне уточнить, что работает с бэкэнд: пользовательский интерфейс очень динамичен. Сообщение из бэкэнд определяет структуру ui и отображаемых данных. Поэтому у нас нет xaml для структуры вкладок, только C#.

В то же время я мог бы решить проблему. Я использовал Snoop и каждый раз обрушивал каждый элемент при мониторинге использования GPU. Я узнал, что на одной из границ был очень крошечный эффект pixhader (DropShadowEffect). Как только я удалил эффект, GPU упал с 80% до 1%. WPF рисовал правильные грязные прямоугольники над небольшими частями пользовательского интерфейса. Проблема решена, дело закрыто.

Что интересно для меня: 1. Огромное влияние этого эффекта на использование графического процессора. 2. Что он нарушает грязный расчет. 3. Поскольку это был не BitmapEffect, а PixelshaderEffect, я не смог его обнаружить, отключив BitmapEffects в Perforator.

Спасибо! MM