C# – WPF drawing performance with large numbers of geometries

cdrawingperformancewpf

I have problems with WPF drawing performance. There are a lot of small EllipseGeometry objects (1024 ellipses, for example), which are added to three separate GeometryGroups with different foreground brushes. After, I render it all on simple Image control. Code:

DrawingGroup tmpDrawing = new DrawingGroup();
GeometryGroup onGroup = new GeometryGroup();
GeometryGroup offGroup = new GeometryGroup();
GeometryGroup disabledGroup = new GeometryGroup();

for (int x = 0; x < DisplayWidth; ++x)
{
    for (int y = 0; y < DisplayHeight; ++y)
    {
        if (States[x, y] == true) onGroup.Children.Add(new EllipseGeometry(new Rect((double)x * EDGE, (double)y * EDGE, EDGE, EDGE)));
        else if (States[x, y] == false) offGroup.Children.Add(new EllipseGeometry(new Rect((double)x * EDGE, (double)y * EDGE, EDGE, EDGE)));
        else disabledGroup.Children.Add(new EllipseGeometry(new Rect((double)x * EDGE, (double)y * EDGE, EDGE, EDGE)));
    }
}

tmpDrawing.Children.Add(new GeometryDrawing(OnBrush, null, onGroup));
tmpDrawing.Children.Add(new GeometryDrawing(OffBrush, null, offGroup));
tmpDrawing.Children.Add(new GeometryDrawing(DisabledBrush, null, disabledGroup));
DisplayImage.Source = new DrawingImage(tmpDrawing);

It works fine, but takes too much time – >0.5s on Core 2 Quad, >2s on Pentium 4. I need <0.1s everywhere. All Ellipses, how you can see, are equal. Background of control, where is my DisplayImage, is solid (black, for example), so we can use this fact. I tried to use 1024 Ellipse elements instead of Image with EllipseGeometries, and it was working much faster (~0.5s), but not enough. How to speed up it?

Regards,
Oleg Eremeev

P.S. Sorry for my English.

Best Answer

I left my old rendering method, but creating new EllipseGeometry object each time was bad idea, so I optimized it in this way:

for (int x = 0; x < newWidth; ++x)
{
    for (int y = 0; y < newHeight; ++y)
    {
        States[x, y] = null;
        OnEllipses[x, y] = new EllipseGeometry(new Rect((double)x * EDGE + 0.5f, (double)y * EDGE + 0.5f, EDGE - 1f, EDGE - 1f));
        OffEllipses[x, y] = new EllipseGeometry(new Rect((double)x * EDGE + 0.5f, (double)y * EDGE + 0.5f, EDGE - 1f, EDGE - 1f));
        DisabledEllipses[x, y] = new EllipseGeometry(new Rect((double)x * EDGE + 0.5f, (double)y * EDGE + 0.5f, EDGE - 1f, EDGE - 1f));
    }
}

// . . .

DrawingGroup tmpDrawing = new DrawingGroup();
GeometryGroup onGroup = new GeometryGroup();
GeometryGroup offGroup = new GeometryGroup();
GeometryGroup disabledGroup = new GeometryGroup();

for (int x = 0; x < DisplayWidth; ++x)
{
    for (int y = 0; y < DisplayHeight; ++y)
    {
        if (States[x, y] == true) onGroup.Children.Add(OnEllipses[x, y]);
        else if (States[x, y] == false) offGroup.Children.Add(OffEllipses[x, y]);
        else disabledGroup.Children.Add(DisabledEllipses[x, y]);
    }
}

tmpDrawing.Children.Add(new GeometryDrawing(OnBrush, null, onGroup));
tmpDrawing.Children.Add(new GeometryDrawing(OffBrush, null, offGroup));
tmpDrawing.Children.Add(new GeometryDrawing(DisabledBrush, null, disabledGroup));
DisplayImage.Source = new DrawingImage(tmpDrawing);

For x = 128 and y = 8 it works really fast, even on Pentium III systems.

Related Solutions

.net – How to use WPF bindings with RelativeSource

If you want to bind to another property on the object:

{Binding Path=PathToProperty, RelativeSource={RelativeSource Self}}

If you want to get a property on an ancestor:

{Binding Path=PathToProperty,
    RelativeSource={RelativeSource AncestorType={x:Type typeOfAncestor}}}

If you want to get a property on the templated parent (so you can do 2 way bindings in a ControlTemplate)

{Binding Path=PathToProperty, RelativeSource={RelativeSource TemplatedParent}}

or, shorter (this only works for OneWay bindings):

{TemplateBinding Path=PathToProperty}

C# – Performance surprise with “as” and nullable types

Clearly the machine code the JIT compiler can generate for the first case is much more efficient. One rule that really helps there is that an object can only be unboxed to a variable that has the same type as the boxed value. That allows the JIT compiler to generate very efficient code, no value conversions have to be considered.

The is operator test is easy, just check if the object isn't null and is of the expected type, takes but a few machine code instructions. The cast is also easy, the JIT compiler knows the location of the value bits in the object and uses them directly. No copying or conversion occurs, all machine code is inline and takes but about a dozen instructions. This needed to be really efficient back in .NET 1.0 when boxing was common.

Casting to int? takes a lot more work. The value representation of the boxed integer is not compatible with the memory layout of Nullable<int>. A conversion is required and the code is tricky due to possible boxed enum types. The JIT compiler generates a call to a CLR helper function named JIT_Unbox_Nullable to get the job done. This is a general purpose function for any value type, lots of code there to check types. And the value is copied. Hard to estimate the cost since this code is locked up inside mscorwks.dll, but hundreds of machine code instructions is likely.

The Linq OfType() extension method also uses the is operator and the cast. This is however a cast to a generic type. The JIT compiler generates a call to a helper function, JIT_Unbox() that can perform a cast to an arbitrary value type. I don't have a great explanation why it is as slow as the cast to Nullable<int>, given that less work ought to be necessary. I suspect that ngen.exe might cause trouble here.

Best Answer

Related Solutions

.net – How to use WPF bindings with RelativeSource

C# – Performance surprise with “as” and nullable types

Related Topic