Проблемы с производительностью запуска приложений WPF / Win32 бок о бок?

Question

У нас есть старая (Win32) и новая (WPF) версия нашего программного обеспечения для блоттера, которое трейдеры в настоящее время работают бок о бок.Однако запуск приложения WPF часто сильно замедляет скорость перерисовки приложения Win32.

Если приложение WPF не запущено (или свернуто), скорость отрисовки в приложении Win32 плавная и быстрая.С открытым приложением WPF скорость отрисовки пользовательского интерфейса приложения Win32 заметно замедляется.Запуск приложения WPF, по-видимому, инициирует использование некоторых ресурсов, которые отнимаются у приложения Win32 (оба графических), вызывая замедление, которое кажется.

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

Одна из гипотез, которая может объяснить причину, заключается в следующем:

Под капотом мы знаем, что и приложения WPF, и Win32 выводят графическую информацию в «насос сообщений» Windows, который в основном представляет собой очередь инструкций о том, чторисовать на экране.Кажется, что когда приложение WPF не запущено, Win32 имеет полный беспрепятственный доступ к нему, и обновления экрана текучие.Одновременно с этим приложение WPF помещает дополнительные сообщения в эту очередь, поэтому приложению Win32 приходится конкурировать за доступ к нему (для каждого обновления элемента экрана), поэтому «забивая насос», что дает видимый эффект.

Если вышеизложенное имеет место, может ли кто-нибудь порекомендовать подходы к управлению / управлению насосом оконных сообщений, чтобы предотвратить это?

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

Если у кого-либо есть какие-либо предложения / идеи, сообщите нам.

Answer 1

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

Примечания ниже:

Похоже, что эта проблема вызвана запуском традиционного 2D-приложения с программным ускорением (X) и трехмерного WPF с аппаратным ускорением (Y) одновременно, и это проблема с графическим драйвером.

Принудительное выполнение Y в режиме программного ускорения WPF также приводит к незначительному снижению производительности прокрутки (поскольку узким местом по-прежнему является код внутренней компоновки сетки).

Однако, что он делает, так это избавляется от проблемы медленного рисования в X, потому что Y теперь работает как 2D-приложение с программным ускорением, как и все другие приложения Windows на машинах трейдера. Это объясняет, почему никакие приложения, кроме Y, не вызывали замедления - кажется, что программные и аппаратно-ускоренные графические приложения не работают хорошо при одновременной работе.

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

К счастью, мы можем отключить аппаратный рендеринг без особого влияния на производительность. После вывода X из эксплуатации мы можем снова включить аппаратное ускорение для незначительных преимуществ, которые оно дает в Y (поддержка более плавной анимации и более интенсивное использование градиентов заливки без замедления и т. Д.).

Answer 2

Каждый процесс будет иметь свой собственный обработчик сообщений - он не используется совместно.

Если вы не видите высокой загрузки ЦП, тогда WPF использует аппаратный рендеринг, так что это может быть насыщение графического процессора.Можете ли вы получить информацию об использовании графического процессора?

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

Программно получить загрузку графического процессора