Performance issues running WPF/Win32 Applications Side by Side?

Question

We have an old (Win32) and new (WPF) version of our blotter software, which the traders are currently running side by side. However, running the WPF application often severly slows down the redraw rate of the Win32 application.

Without the WPF application running (or minimized), draw rate is fluid and fast in the Win32 application. With the WPF application open alongside it, the Win32 appl's UI draw rate slows down noticeably. Running the WPF application seems to trigger use of some resources which are taken away from the Win32 app (both graphics-heavy) - causing the slow down it seems.

CPU and Memory are not anywhere near being saturated, so it doesn't seem to be related to those. Lowering resolution and/or reducing the number of monitors to display on (therefore decreasing video card memory usage and bandwidth load) makes no noticeable difference, therefore it doesn't seem to be a graphics hardware performance issue either.

One hypothesis that may explain the cause is as follows:

Under the hood, we know that both the WPF and Win32 applications output graphics information to a windows "message pump" which is basically a queue of instructions of what to draw to the screen. It seems as if when the WPF application is not running, the Win32 has full unfettered access to this and screen updates are fluid. Running the WPF application alongside it puts additional messages on this queue, so Win32 application has to compete harder for access to it (in order to do each screen element update), therefore "clogging the pump" giving the effect we see.

If the above is the case, can anyone recommend approaches to manage/control the window message pump in order to prevent this happening?

The flicker is the type you typically get when resources run low, where you can see individual elements (forms, labels) flicker and gradually draw on to the screen.

If anyone has any suggestions/ideas, let us know.

Answer 1

Each process will have its own message pump - this is not shared.

If you are not seeing high CPU utilization, then WPF is using hardware rendering, so it could possibly be GPU saturation. Can you get information on GPU utilization?

The following post details methods of getting GPU utilization:

Programmatically fetch GPU utilization

Answer 2

Okay, I think we've found the cause, and fix. In a nutshell, hardware and software accelerated windows don't play nice. Using software-rendering across the board fixes glitches that were previously there when running hardware-accelerated windows. Since our legacy Win32 app will be decommissioned soon, this is a workable comprimise - we can simply switch hardware acceleration back on when we drop the legacy application.

Notes below:

It seems like this issue is being caused by running a traditional software-accelerated 2D application (X) and 3D hardware-accelerated WPF one (Y) at the same time, and is a graphics driver issue.

Forcing Y to run in WPF software-acceleration mode as well causes little degradation in scrolling performance (as the bottleneck is still the grid's internal layout code).

However, what it does do, is get rid of the slow drawing issue in X, because Y is now running as a software-accelerated 2D application, like all other Windows applications on trader's machines. This explains why no applications other than Y caused slowdown - it seems as if software and hardware-accelerated graphics applications don't play nice when run at the same time.

This makes sense - when I play a hardware-accelerated game, for instance, I've seen similar (where the desktop redraws very slowly when switching to/from the game between hardware/software acceleration modes).

Thankfully we can turn off hardware-rendering without much impact in performance. Once X is decommissioned we can switch hardware-acceleration back on for the minor benefits it provides in Y (support for smoother animations and heavier use of fill gradients without slowing down etc).