Running WPF Application with Multiple UI Threads

Introduction

It’s a good, time-proven practice to perform long, CPU intensive tasks on some sort of a background thread to improve your UI thread responsiveness. Sometimes though UI-related tasks themselves can be quite expensive. WPF, for examples, forces you to do all UI work on the thread that created the UI. A very flexible WPF measure/layout paradigm for UI rendering also comes with high CPU usage cost. In a very UI intensive application (for example, trading app with about ten windows showing real-time montage and blotter data) simply the cost of generating and laying out visuals can become too high for a single thread to keep up. When your UI thread saturates individual windows may start skip rendering cycles, become slow to response to user input, or even freeze. If your UI thread approaches this kind of saturation you should consider creating dedicated UI threads for some (or all) of your UI-intensive windows. This post is a step by step walk-through of doing just that.

Creating single-threaded WPF UI application

To start lets create a basic WPF application we can work with. In Visual Studio go File/New/Project, then Visual C#, Windows, WPF Application. Name the project “WpfThreadLab” and click “OK”. The automatically generated Window1.xaml window doesn’t display anything by default, so let add something useful for out lab. We will display the ID for the thread that owns the window. First open Window1.xaml.cs and add the following code”:

using System.Threading;
using System.Windows;

namespace WpfThreadLab
{
 /// <summary>
 /// Interaction logic for Window1.xaml
 /// </summary>
 public partial class Window1 : Window
 {
  public Window1()
  {
   InitializeComponent();

   Thread thread = Thread.CurrentThread;
   this.DataContext = new
   {
    ThreadId = thread.ManagedThreadId
   };
  }

  private void OnCreateNewWindow(
   object sender,
   RoutedEventArgs e)
  {
    Window1 w = new Window1();
    w.Show();
  }

 }
}

Constructor creates data context containing thread’s ID that we can data bind to. We also add a click event handler that we will use to create new windows on demand. This is how corresponding Window1.xaml may look like:

<Window
    x:Class="WpfThreadLab.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="100" Width="200"
>
 <StackPanel>
  <StackPanel Orientation="Horizontal">
   <TextBlock Text="Thread's ID is "/>
   <TextBlock Text="{Binding ThreadId}"/>
  </StackPanel>
  <Button
   Click="OnCreateNewWindow"
   Content="Create new Window1"
  />
 </StackPanel>
</Window>

If you run the application now you should see the following window:

Clicking on the button will create new clones of the window. You will see that they all belong to default UI thread with managed ID 1.

Adding code to create dedicated UI threads for each window

The quick and dirty solution may include the following modifications to our OnCreateNewWindow handler:

private void OnCreateNewWindow(
 object sender,
 RoutedEventArgs e)
{
 Thread thread = new Thread(() =>
  {
   Window1 w = new Window1();
   w.Show();
  });

 thread.SetApartmentState(ApartmentState.STA);
 thread.Start();
}

The window creation code is exactly the same, except that we wrapped it in a thread delegate. This delegate is passed to a newly created thread that is started at the end of the handler. Note that we explicitly setting new thread’s apartment state to STA, this is a WPF requirement.

If you run the application now and click on the button, you will notice that a new window appears momentarily and then dies. The reason is that our newly created thread is not enabled to support WPF window infrastructure. In particular, it provides no support for Windows message pumping, and this is something we will fill in next.

Making a thread “UI thread”

WPF window like any other window relies on Windows message pump. In WPF word this functionality is provided by a class called Dispatcher. WPF Application object takes care of starting dispatcher for the main UI thread for us, but we have to explicitly start it for our own private UI threads. The easiest way to do it is to call static method Run() on the Dispatcher class:

private void OnCreateNewWindow(
 object sender,
 RoutedEventArgs e)
{
 Thread thread = new Thread(() =>
  {
   Window1 w = new Window1();
   w.Show();

   System.Windows.Threading.Dispatcher.Run();
  });

 thread.SetApartmentState(ApartmentState.STA);
 thread.Start();
}

The code in bold shows the modification. This blocks the thread and starts a message pump on it. If you run application now and start clicking the button you will notice that fully functional window is created every time you click, and every time on a new thread.

There is one catch to our simplified solution. Closing a particular window does NOT terminate this window’s thread dispatcher, so the thread keeps running and, after closing all windows, the process will not terminate and will become a ghost process. Simple (and not correct) solution to this is to mark our threads as background (using thread.IsBackground = true;). This will force them to terminate when main UI thread terminates. The proper implementation will gracefully shut down the dispatcher when it is no longer needed. The code below is an example of a strategy to terminate the dispatcher when window closes:

private void OnCreateNewWindow(
   object sender,
   RoutedEventArgs e)
  {
   Thread thread = new Thread(() =>
    {
     Window1 w = new Window1();
     w.Show();

     w.Closed += (sender2, e2) =>
      w.Dispatcher.InvokeShutdown();

     System.Windows.Threading.Dispatcher.Run();
    });

   thread.SetApartmentState(ApartmentState.STA);
   thread.Start();
  }

The code above in bold accomplishes the task of shutting down the dispatcher for window’s UI thread.

Conclusion

Running multiple UI threads in WPF application is actually rather trivial. In the nutshell it boils down to creating your dedicated thread and creating your windows inside this thread’s proc. Remember to conclude your UI thread with a call to WPF dispatcher. Also, decide on your “exit” strategy (often, shutting down dispatcher in response to closing the primary window for this thread).

• Dispatcher
• Threads
• UI
• WPF