Wpf – In what order are Panels the most efficient in terms of render time and performance

panelperformancerenderingwpf

There are many times when more than one panel would suitable for the layout I want, however I know there is a difference in render times for different panel types.

For example, MSDN states that

A relatively simple Panel, such as Canvas, can have significantly
better performance than a more complex Panel, such as Grid.

So in terms of render time and performance, in what order are WPF panels the most efficient?

WPF Panels:

Canvas
DockPanel
Grid
UniformGrid
StackPanel
WrapPanel
VirtualizingPanel / VirtualizingStackPanel

I'm fairly sure I saw a list of this somewhere online, but I can't find it now.

The ideal answer I am looking for would provide me a list of panels in the order that they would render fastest. I understand the number of children is a big factor in how efficient the panels are, so for the sake of this question, assume each panel only has a Label/TextBox pair.

In addition, I would like a list of exceptions, such as specific panels which perform better than others based on certain conditions.

Update

To summarize based on the accepted answer below, the panel performance is based on the number and layout of child items, however in general the list from fastest to slowest is:

Canvas
StackPanel
WrapPanel
DockPanel
Grid

In addition, a VirtualizingPanel / VirtualizingStackPanel should always be used if there are a lot of items that don't always fit on the screen.

I'd highly recommend you read the accepted answer below for more details before just picking an item from this list.

Best Answer

I think it is more concise and understandable to describe the performance characteristics of each panel than it is to try to give an absolute relative performance comparison.

WPF makes two passes when rendering content: Measure and Arrange. Each panel has different performance characteristics for each of these two passes.

The performance of the measure pass is most affected by the ability of a panel to accommodate stretching using alignments (or Auto in the case of the Grid) and then the number of children which are stretched or auto-sized. The performance of the Arrange pass is affected by the complexity of the interaction between layout location of different children and then of course the number of children.

At times the given panels don't easily lend themselves to the needed layout. I created a control that needed an arbitrary number of items to each be positioned at a certain percentage of the available space. None of the default controls do this. Attempting to make them do this (via binding to the actual size of the parent) results in horrible performance. I created a layout panel based on the Canvas which achieved my desired result with minimal work (I copied the source for the canvas and modified around 20 lines of it).

Available Panels:

Canvas

Defines an area within which you can explicitly position child elements by coordinates relative to the Canvas area.

The Canvas has the best performance of all the panels for the arrange pass since each item is statically assigned a location. The measure pass also has excellent performance since there is no concept of stretching in this panel; each child simply uses its native size.
DockPanel

Defines an area within which you can arrange child elements either horizontally or vertically, relative to each other.

The Dockpanel has a very simple layout scheme where items are added one by one relative to the previous item added. By default either the height or width is determined by the item's native size (based on Top/Bottom vs Left/Right respectively) and the other direction is determined by the Dock property if the width or height is undefined. Medium to fast measure pass and medium to fast arrangement pass.
Grid

Defines a flexible grid area that consists of columns and rows.

This can be the most performance intensive panel if proportional sizing or auto sizing is used. Calculating child item size can be a complex combination of the native size of the item and the layout specified by the grid. Layout is also the most complicated of all the panels. Slow to medium performance for the measure pass and slow to medium performance for the arrangement pass.
StackPanel

Arranges child elements into a single line that can be oriented horizontally or vertically.

The StackPanel measures its children using either native or relative sizing in the opposite direction from its orientation and native sizing in the direction of its orientation (alignment does nothing in this direction). This makes it a mid-level performer in this area. The Arrangement pass is simply, just laying out the items in order. Probably the second-best performance for this pass. Medium performance for the measure pass and fast performance for the layout pass.
VirtualizingPanel

Provides a framework for Panel elements that virtualize their child data collection. This is an abstract class.

A base class for implementing your own virtualizing panel. Only loads visible items to prevent unneeded use of memory and processor. MUCH more performant for sets of items. Probably slightly less performant for items that fit on the screen due to the bounds checking. The SDK only provides one subclass of this, the VirtualizingStackPanel.
WrapPanel

Positions child elements in sequential position from left to right, breaking content to the next line at the edge of the containing box. Subsequent ordering occurs sequentially from top to bottom or right to left, depending on the value of the Orientation property.

The measure pass is a somewhat complex pass where the largest item for a particular row determines the height of the row and then each item on that row either uses its native height (if it has one) or the height of the row. The layout pass is simple, putting each item one after the other on a row and then continuing onto the next row when there is not enough room for the next item. Medium performance measure pass. Medium to fast performance for the arrangement pass.

References:

Use the Most Efficient Panel where Possible

The complexity of the layout process is directly based on the layout behavior of the Panel-derived elements you use. For example, a Grid or StackPanel control provides much more functionality than a Canvas control. The price for this greater increase in functionality is a greater increase in performance costs. However, if you do not require the functionality that a Grid control provides, you should use the less costly alternatives, such as a Canvas or a custom panel.

From Optimizing Performance: Layout and Design

The layout system completes two passes for each member of the Children collection, a measure pass and an arrange pass. Each child Panel provides its own MeasureOverride and ArrangeOverride methods to achieve its own specific layout behavior.

During the measure pass, each member of the Children collection is evaluated. The process begins with a call to the Measure method. This method is called within the implementation of the parent Panel element, and does not have to be called explicitly for layout to occur.

First, native size properties of the UIElement are evaluated, such as Clip and Visibility. This generates a value named constraintSize that is passed to MeasureCore.

Secondly, framework properties defined on FrameworkElement are processed, which affects the value of constraintSize. These properties generally describe the sizing characteristics of the underlying UIElement, such as its Height, Width, Margin, and Style. Each of these properties can change the space that is necessary to display the element. MeasureOverride is then called with constraintSize as a parameter.

Note There is a difference between the properties of Height and Width and ActualHeight and ActualWidth. For example, the ActualHeight property is a calculated value based on other height inputs and the layout system. The value is set by the layout system itself, based on an actual rendering pass, and may therefore lag slightly behind the set value of properties, such as Height, that are the basis of the input change. Because ActualHeight is a calculated value, you should be aware that there could be multiple or incremental reported changes to it as a result of various operations by the layout system. The layout system may be calculating required measure space for child elements, constraints by the parent element, and so on. The ultimate goal of the measure pass is for the child to determine its DesiredSize, which occurs during the MeasureCore call. The DesiredSize value is stored by Measure for use during the content arrange pass.

The arrange pass begins with a call to the Arrange method. During the arrange pass, the parent Panel element generates a rectangle that represents the bounds of the child. This value is passed to the ArrangeCore method for processing.

The ArrangeCore method evaluates the DesiredSize of the child and evaluates any additional margins that may affect the rendered size of the element. ArrangeCore generates an arrangeSize, which is passed to the ArrangeOverride method of the Panel as a parameter. ArrangeOverride generates the finalSize of the child. Finally, the ArrangeCore method does a final evaluation of offset properties, such as margin and alignment, and puts the child within its layout slot. The child does not have to (and frequently does not) fill the entire allocated space. Control is then returned to the parent Panel and the layout process is complete.

From Measuring and Arranging Children

Related Solutions

Java – What are the effects of exceptions on performance in Java

It depends how exceptions are implemented. The simplest way is using setjmp and longjmp. That means all registers of the CPU are written to the stack (which already takes some time) and possibly some other data needs to be created... all this already happens in the try statement. The throw statement needs to unwind the stack and restore the values of all registers (and possible other values in the VM). So try and throw are equally slow, and that is pretty slow, however if no exception is thrown, exiting the try block takes no time whatsoever in most cases (as everything is put on the stack which cleans up automatically if the method exists).

Sun and others recognized, that this is possibly suboptimal and of course VMs get faster and faster over the time. There is another way to implement exceptions, which makes try itself lightning fast (actually nothing happens for try at all in general - everything that needs to happen is already done when the class is loaded by the VM) and it makes throw not quite as slow. I don't know which JVM uses this new, better technique...

...but are you writing in Java so your code later on only runs on one JVM on one specific system? Since if it may ever run on any other platform or any other JVM version (possibly of any other vendor), who says they also use the fast implementation? The fast one is more complicated than the slow one and not easily possible on all systems. You want to stay portable? Then don't rely on exceptions being fast.

It also makes a big difference what you do within a try block. If you open a try block and never call any method from within this try block, the try block will be ultra fast, as the JIT can then actually treat a throw like a simple goto. It neither needs to save stack-state nor does it need to unwind the stack if an exception is thrown (it only needs to jump to the catch handlers). However, this is not what you usually do. Usually you open a try block and then call a method that might throw an exception, right? And even if you just use the try block within your method, what kind of method will this be, that does not call any other method? Will it just calculate a number? Then what for do you need exceptions? There are much more elegant ways to regulate program flow. For pretty much anything else but simple math, you will have to call an external method and this already destroys the advantage of a local try block.

See the following test code:

public class Test {
    int value;


    public int getValue() {
        return value;
    }

    public void reset() {
        value = 0;
    }

    // Calculates without exception
    public void method1(int i) {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            System.out.println("You'll never see this!");
        }
    }

    // Could in theory throw one, but never will
    public void method2(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // Will never be true
        if ((i & 0xFFFFFFF) == 1000000000) {
            throw new Exception();
        }
    }

    // This one will regularly throw one
    public void method3(int i) throws Exception {
        value = ((value + i) / i) << 1;
        // i & 1 is equally fast to calculate as i & 0xFFFFFFF; it is both
        // an AND operation between two integers. The size of the number plays
        // no role. AND on 32 BIT always ANDs all 32 bits
        if ((i & 0x1) == 1) {
            throw new Exception();
        }
    }

    public static void main(String[] args) {
        int i;
        long l;
        Test t = new Test();

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            t.method1(i);
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method1 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method2(i);
            } catch (Exception e) {
                System.out.println("You'll never see this!");
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method2 took " + l + " ms, result was " + t.getValue()
        );

        l = System.currentTimeMillis();
        t.reset();
        for (i = 1; i < 100000000; i++) {
            try {
                t.method3(i);
            } catch (Exception e) {
                // Do nothing here, as we will get here
            }
        }
        l = System.currentTimeMillis() - l;
        System.out.println(
            "method3 took " + l + " ms, result was " + t.getValue()
        );
    }
}

Result:

method1 took 972 ms, result was 2
method2 took 1003 ms, result was 2
method3 took 66716 ms, result was 2

The slowdown from the try block is too small to rule out confounding factors such as background processes. But the catch block killed everything and made it 66 times slower!

As I said, the result will not be that bad if you put try/catch and throw all within the same method (method3), but this is a special JIT optimization I would not rely upon. And even when using this optimization, the throw is still pretty slow. So I don't know what you are trying to do here, but there is definitely a better way of doing it than using try/catch/throw.

.net – In WPF, what are the differences between the x:Name and Name attributes

There really is only one name in XAML, the x:Name. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name by using the RuntimeNamePropertyAttribute on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.

The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement introduces a Name property.

In general, a class does not need to store the name for x:Name to be useable. All x:Name means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.

So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.

In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.

Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.

See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.

Best Answer

Related Solutions

Java – What are the effects of exceptions on performance in Java

.net – In WPF, what are the differences between the x:Name and Name attributes

Related Topic