WPF Textblock Performance Poor

Question

I have been having trouble with the WPF DataGrid and listbox GridView performance when displaying even small amounts of data. I though this problem was simply WPF having poor performance in general, but the problem seems to lie in the textblock control only.

I created a sample panel that I added several items to. If I add rectangles that are simply filled, the resizeing/scroll performance is perfect, but once I use textblocks, the performance goes out the window.

It looks like the performance issue arises from:

child.Measure(constraint); 

When the textblock gets measured, it brings performance to a grinding halt. Is there anything that I can to to override the measurement of a textblock or something to improve performance? (I will set the size of the children explicitly)

EDIT: I have now created simplified code to arrange the items as I wanted.

The performance of this code is great except...when the width of the text inside the textblock exceed the actual width of the textblock. This brings my performance back down to a crawl - possibly because it is trying to measure the elements again?

 public class TestPanel : Panel
{
    private int _rowHeight = 20;
    private int _columnWidth = 50;

    public TestPanel()
    {

        for (int i = 0; i < 100; i++)
        {

            for (int j = 0; j < 20; j++)
            {
                TextBlock cell = new TextBlock();
                cell.ClipToBounds = true;
                cell.Width = _columnWidth;
                cell.Height = _rowHeight;
                cell.Text = i.ToString() + ":" + j.ToString();
                this.Children.Add(cell);
            }
        }
    }

    protected override Size MeasureOverride(Size constraint)
    {
        return new Size(_columnWidth*20,_rowHeight*100);
    }

    protected override Size ArrangeOverride(Size arrangeBounds)
    {
        UIElementCollection children = InternalChildren;

        for (int i = 0; i < 100; i++)
        {
            for (int j = 0; j < 20; j++)
            {
                UIElement child = children[i*20+j];
                child.Arrange(new Rect(j * _columnWidth, i * 20, _columnWidth, 20));
            }
        }
        return arrangeBounds;
    }
}

public MainWindow()
    {
        InitializeComponent();

        TestPanel myPanel = new TestPanel();
        ScrollViewer scroll = new ScrollViewer();

        myPanel.Background = Brushes.Aqua;

        scroll.Content = myPanel;
        this.Content = scroll;

    }

Cisneros

Answer 1

The performance difference between TextBox and Rectangle is due to the different complexity of these controls. Just compare the complexity of the resulitng visual trees (i.e. using XamlPad). A Rectangle most likely just knows its desired size. A TextBox, on the other hand, needs to consider many different factors when calculating the desired size, such as the desired size of the acutal text (I guess this is the real bottleneck).

Having that said, there are some optimizations you might want to try. The goal of the measure pass is to determine your desired size. Furthermore, you propagate the measure pass by calling measure on all child elements. However, you only need to do this if you expect a change of the desired size. It seems like you know a lot about your layout having _rowHeight and _columnWidth fields. So do the following:

• Measure your children using: child.Measure(new Size(_columnWidth, _rowHeight)). This is the actual constraint right?
• Reduce the number of measure runs for your child elements. Do this by moving all this code out of MeasureOverride and only call this function if _rowHeight or _lineWidth changes (also, this will be the method which calls Measure on your child elements). Implement these fields as DependencyProperties to be able to listen to changes (you can use INotifyPropertyChanged if you don't like DependencyProperties)
• Most likely, you can implement MeasureOverride (now without having to measure your child elements) in constant time (e.g. numberOfColumns * _columnWidth...)
• Implement similar logic for ArrangeOverride.
• In other words: don't do layout logic (i.e. deciding questions like "does this element fit into this line") in MeasureOverride/ArrangeOverride

This approach, however, does not respect the desired size of the TextBox elements. You can either not care or solve this separately:

• Listen to text changes, choose the appropriate event.
• If the text in a TextBox changes, call Measure only for this particular text box. (You can measure this textbox with positive infinity as constraint)
• Adapt your ColumnWidth and RowHeight properties

Apart from improving your MeasureOverride/ArrangeOverride implementations you can use a different (e.g. more lightweight) ControlTemplate for the TextBox. I would opt for rewriting MeasureOverride/ArrangeOverride.

Albumin

It appears that even if I override the measure override of the layout panel, a measure occurs when the text is longer than the block is. Is there any good way to prevent this from happening? – Cisneros

Answer 2

First of all, after testing your code it appears that you've rewritten the WrapPanel that already exists in WPF. When I replaced your TestPanel with the WrapPanel the behavior was exactly the same, with an improvement to performance.

Secondly, I am wondering what kind of hardware, specifically, video card you are using. When I ran this sample on my PC I saw little to no lag. Certainly not the "grinding halt" that you are speaking of.

Finally, the only way I know of to improve the performance of text-rendering is to use low-level text objects. FormattedText comes to mind. This is far more difficult to work with than TextBlock, however, so I would encourage you to think about what it is you are trying to accomplish before switching to FormattedText.

EDIT:

The real area where WPF is hurting your performance is in the Measure and Arrange passes of the layout system. It's important to understand that every time you resize the window, WPF is re-calculating the sizes and positions of every user-interface element, and then rearranging them accordingly. This is extremely useful for achieving flexible layouts or creating dynamic user interfaces, but for a static grid of data (which seems to be what you have in mind), this is doing more harm than good. On most machines, WPF will offload as much work as possible to the GPU. In your case, however, the CPU is handling everything, hence the "churn" you are seeing on resize.

FormattedText would be faster, but would not lend itself to working with a data-grid. Rather than writing your own layout panel (a 1% scenario in WPF), I would switch to a ListView or a third-party grid component and see how performance is at that point. These kind of components are built (and optimized) to display vast rows of changing data-- the WPF layout panels are built to contain other user interface elements and drawings.

Wellestablished

well, I am currently on my laptop w/ a T4200 (2.00 Ghz dual core) w/ 2 gigs of ram & onboard graphics - which is a step up from the computers at my work that would be running this - ~3 Ghz old school pentium 4 w/ no dedicated graphics card. I know that I re-wrote the wrap panel - my ultimate goal is to have a datagrid, but I was just trying to test panels for now...Do you think that FormattedText would be much faster than a TextBlock? – Cisneros

Thank you for your additional input. I have tried working with a listview before, with minimal performance increases over a standard datagrid, and a 3rd party control is not possible at this time. I am still fairly new to writing custom panels - is there a simple way to write the arrange & measure procedures to not have to perform complex calculations if I know the size of each cild, exactly how many children per line and the # of lines I will have? – Cisneros