ColorLine performance

[Charles Cruden]

Using TeeChart.WPF.dll 4.00.2009.35592, we are trying to build a "cursor" type object into the chart that will let a user grab a line perpendicular to the X axis that crosses the entire trend, move it to wherever they think it is of interest and determine the value of all the series in the trend at that point. Using the ColorLine tool and some AnnotationTools at the points where it intersected series seemed like the obvious method to do this, but we are finding the performance of the chart using ColorLine is ... pretty bad. This seems to be because every time the ColorLine object is moved, the chart redraws. This happens whether or not ColorLine.DragRedraw is set to false. (The only effect setting it to false seems to have is that the line itself disappears while it's being dragged, which is not particularly helpful. We confirmed the redraw was happening both through profiling and by adding some console output from the TChart.AfterDraw event.) Using a FastLine instead of a Line series speeds up the redraw a bit, but it's still quite choppy on our expected average hardware (Intel 965 integrated graphics). Is there any way this redraw can be eliminated or sped up in some way?

[Charles Cruden]

Just for reference, we've gone through the suggestions in the real-time charting performance article on the site: we are using FastLine with DrawAllPoints set to false (although the number of points is about the same as the width of the chart); there is no FastPen property on the FastLine in the .NET version; and the remaining issues it addresses are all for adding or removing data to the series, which isn't happening while the ColorLine is being moved around on the screen.

[Narcís]

Hi Charles,

Have you tried using CursorTool instead of ColorLine tool? You can find a TeeChart.WPF and CursorTool example here. If this doesn't help please attach a simple example project with we can reproduce the problem here and we will try to optimize its performance.

Thanks in advance.

[Charles Cruden]

Yes, the CursorTool suffers from the same problem. I did notice that in the WPF version of TeeChart at least, FastCursor is not an implemented property on CursorTool, so it more or less guarantees that a redraw will occur each time the cursor is moved. Is there any chance that will be changed soon?

A quick demonstration is to use the source from the Examples/DemoProjectWPF folder distributed with the TeeChart install. Instead of using a single series, use three (so replace chart.Series.Add(new Line()); with three such calls) and make each line have 1000 points (replace Chart[0].FillSampleValues(); with Chart[0].FillSampleValues(1000); Chart[1].FillSampleValues(1000); Chart[2].FillSampleValues(1000);). Run the program and select the ColorLine tool and try to drag the cursor around. You won't really see anything on the screen, but your processor usage will ramp up. (On my machine (a VM running on a Core2 E6700 with an i965 graphics controller), it pegs the CPU at 100%. If I set the ColorLine.DragRepaint to true, the effect is the same and cursor movement is very choppy.) If you add an AfterDraw handler to the chart which simply does

Code: Select all

    
void tChart1_AfterDraw(object sender, Graphics3D g)
    {
        Console.WriteLine("AfterDraw");
    }

and repeat the same thing while running the program through a debug session in Visual Studio, you'll see your output window fill with AfterDraw messages. This happens regardless of the value if ColorLine.DragRepaint.

[Narcís]

Hi Charles,

Thanks for your feedback. I could reproduce the behavior you reported here. Using ColorLine with DragRepaint to true code below response is pretty good. Even better using CursorTool. Anyway, WinForms equivalent application performs much better.

Code: Select all

    public Window1()
    {
      InitializeComponent();
      InitializeChart();
    }

    private void InitializeChart()
    {
      tChart1.Aspect.View3D = false;

      for (int i = 0; i < 3; i++)
      {
        tChart1.Series.Add(new Steema.TeeChart.WPF.Styles.Line());
        tChart1[i].FillSampleValues(1000);
      }

      Steema.TeeChart.WPF.Tools.ColorLine colorLine1 = new Steema.TeeChart.WPF.Tools.ColorLine(tChart1.Chart);
      colorLine1.Axis = tChart1.Axes.Bottom;
      colorLine1.DragRepaint = true;

      //Steema.TeeChart.WPF.Tools.CursorTool cursor1 = new Steema.TeeChart.WPF.Tools.CursorTool(tChart1.Chart);

      tChart1.AfterDraw += new Steema.TeeChart.WPF.PaintChartEventHandler(tChart1_AfterDraw);
    }

    void tChart1_AfterDraw(object sender, Steema.TeeChart.WPF.Drawing.Graphics3D g)
    {
      Console.WriteLine("AfterDraw");
    }

We are constantly working in increasing TeeChart.WPF.dll performance. However, WPF is slower than GDI+ and WinForms applications. Although WPF is faster in some areas, such as painting, it is slower in other areas as extra objects have to be created to be passed to the painting method. All WPF pen objects expect a brush to define their appearance. This makes pens very flexible, but means that just to set a pen to a red color, for example, a new brush has to be created. On balance, therefore, as for the investigation and tests we have done so far, we do not expect the WPF chart to be as quick as the GDI+ chart for large datasets. We don’t think WPF was designed for intensive drawing, it was designed for aesthetic drawing.

For enhancing your applications performance you could also filter your data using DownSampling function as shown in the All Features\Welcome !\Functions\Extended\Reducing number of points examples at the features demo, available at TeeChart's program group.

[tomc]

This was 7 years ago and I am now finding the same issue with cursor redraw on lots of points in WPF. Did this problem ever get addressed?

[Christopher]

This was 7 years ago and I am now finding the same issue with cursor redraw on lots of points in WPF. Did this problem ever get addressed?

In the last 7 years Microsoft has released eight versions of the .NET Framework (4.0, 4.5, 4.51, 4.52, 4.6, 4.61, 4.62, and 4.7), and this along with improvements in hardware speeds, particularly in the GPU area, would lead me to expect some not insignificant gains in speed in this area.

However, as far as we know, the WPF framework has not made available any new API elements which would significantly improve rendering. Any improvements, on our understanding, have come through code optimization and hardware acceleration, as mentioned above.