Displaying streaming rich text with WPF

Question

I have a WPF application that connects via a socket to a device and gets streaming text data (approx 1 message per second). This data is then displayed on the UI. The user can

Answer 1

This idea complicates things significantly, but my thought would be to create one viewer per message and create only as many viewers as are necessary to display the currently visible messages. I think the VirtualizingStackPanel control would be a good tool to manage this. I found a series describing the implementation of a VirtualizingStackPanel here.

Obviously, this implies maintaining the message buffer in a separate data structure.

EDIT: I just realized that the standard ListBox control uses a VirtualizingStackPanel in its implementation. With this in mind, my revised suggestion is:

1. Create a data structure to contain the source of each message.
2. Create a property on the data structure that creates a FlowDocument from the message source "on the fly"
3. Bind a ListBox to a collection of said data structures.
4. Define the ItemTemplate for the ListBox with a FlowDocumentScrollViewer where the Document property is bound to the aforementioned data structure's property.

EDIT 2: Regarding printing/zooming: I can't help you much with printing in WPF (something involving VisualBrush, maybe?), but zooming should be pretty easy to do. I created a ZoomListBox to test this idea. The XAML looks like this:

<ListBox
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    x:Class="Test.ZoomListBox"
    d:DesignWidth="640" d:DesignHeight="480"
    x:Name="ThisControl">
    <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
            <VirtualizingStackPanel IsItemsHost="True">
                <VirtualizingStackPanel.LayoutTransform>
                    <ScaleTransform ScaleX="{Binding ElementName=ThisControl, Path=Zoom}" ScaleY="{Binding ElementName=ThisControl, Path=Zoom}" />
                </VirtualizingStackPanel.LayoutTransform>
            </VirtualizingStackPanel>
        </ItemsPanelTemplate>
    </ListBox.ItemsPanel>
</ListBox>

And the code behind is this:

public partial class ZoomListBox
{
    public ZoomListBox()
    {
        this.InitializeComponent();
    }

    public double Zoom
    {
        get { return (double)GetValue(ZoomProperty); }
        set { SetValue(ZoomProperty, value); }
    }

    // Using a DependencyProperty as the backing store for Zoom.  This enables animation, styling, binding, etc...
    public static readonly DependencyProperty ZoomProperty =
        DependencyProperty.Register("Zoom", typeof(double), typeof(ZoomListBox), new UIPropertyMetadata(1.0));
}

And an example of using it:

<Grid x:Name="LayoutRoot">
    <Grid.RowDefinitions>
        <RowDefinition />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>
    <l:ZoomListBox x:Name="ZoomList">
        <Button>Foo</Button>
        <Button>Foo</Button>
        <Button>Foo</Button>
        <Button>Foo</Button>
        <Button>Foo</Button>
        <Button>Foo</Button>
        <Button>Foo</Button>
    </l:ZoomListBox>
    <Slider Grid.Row="1" Value="{Binding ElementName=ZoomList, Path=Zoom}" Minimum="0.5" Maximum="5" /> 
</Grid>

Answer 2

FlowDocumentScrollViewers may have overhead due to the ability to display content in columns, etc. Is there a reason that a normal WPF RichTextBox won't work? Also, do you have .NET 3.5 SP1? The following link indicates that there have been big performance improvements for FlowDocuments in SP1: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/a116da54-ce36-446a-8545-3f34e9b9038d.

Answer 3

The performance breakdown seemed to be caused by the high number of Blocks in the FlowDocument. For every message received I was creating a Run, adding that run to a Paragraph and adding the paragraph to the document.

I changed the algorithm so now it creates a Paragraph then adds 250 Runs to that Paragraph, then creates a new Paragraph ... adds 250 Runs ... and so on. This essentially cuts the number of blocks in half.

This also has an added benefit when I reach the max number of lines (10,000). Instead of deleting a single line for each new line added (and pegging the CPU), I can just delete the oldest Paragraph and that instantly deletes the oldest 250 lines.

This relatively simple change brought the performance well within the acceptable range. Instead of pegging the CPU and locking up the UI, now the CPU stays relatively low with spikes around 15%.