Cursor Tool Performance?

[Pep]

Have you tried adding the Refresh method in the OnCursorTool_Change event like :

Code: Select all

private void cursorTool1_Change(object sender, Steema.TeeChart.Tools.CursorChangeEventArgs e)
{
    int aspWidth = tChart1.Aspect.Width3D;
    tChart1.Refresh();
    for(int i = tChart1.Axes.Left.CalcYPosValue(line1.YValues.Maximum) - aspWidth;	i <= tChart1.Axes.Left.CalcYPosValue(line1.YValues.Minimum) + aspWidth; ++i) 
    {				
          if(line1.Clicked(e.x, i) != -1) 
          {
               double yValue1 = tChart1.Axes.Left.CalcPosPoint(i);
               label1.Text = "Line 1 - YValue : "+yValue1.ToString();
           }
     }
}

?

[swong]

The Refresh() property doesn't seem to affect the performance at all.

Do you have any other suggestions?

Thanks!

[Christopher]

Hi --

Do you have any other suggestions?

How about using a FastLine series and:
fastlineSeries1.DrawAllPoints = false ;

as in the example in the Features Demo under:
All Features -> Welcome! -> Speed -> Fastline Speed DrawAll.

[swong]

I actually am using the fastline series. (With the DrawAllPoints = false;). I've noticed that the Paint() or the chart area is extremely long. Could you try the following:

- Series of 150,000+ points
- Maximize the Chart control
- Place another window on top of the window that has the chart
- Drag the window around the chart control and watch it refresh

On my laptop (AMD 2500+) it takes approx 5 seconds to repaint, even if another window just barely touches the chart control. It seems that the control re-computes the series lines, as opposed to redrawing from a cache.

The same seems true for the cursor tool. Instead of xoring the previous line, it seems the whole control repaints, and draws the cursor where it needs to. If the cursor tool is initially off, then turned on, it seems quicker than when the cursor is on and moved to a different location.

[Christopher]

Hi -

Could you try the following:

Sure. On my desktop (Pentium 4 1700 running Windows v5.2.3790) the repaint of TeeChart for .NET v1.0.1189.31308 takes just under 2 seconds for 150.000 points.

[swong]

Even 2 seconds seems a bit slow doesn't it? What I am trying to do is implement floating toolbars, but moving a toolbar across the chart causes a delay. The same applies to dragging Marks, etc across the graph. I have to click (an hold) for about 2-5 seconds before I can move the label.

Is there some way to stop the update of the screen until after an operation is completed (ie. after the window has been moved, etc)?

Thanks again for your prompt responses!

[Christopher]

Hi --

Even 2 seconds seems a bit slow doesn't it?

Well, I'm sure this figure would be lower on a more up-to-date machine.

Is there some way to stop the update of the screen until after an operation is completed (ie. after the window has been moved, etc)?

Mmmm, you might want to experiment with the Steema.TeeChart.TChart.AutoRepaint Property.

[johnnyboyc]

I ended up rolling my own cursor drawing facility because of the slow speed of the existing CursorTool; it makes fairly heavy use of GDI via Interop but it's lightning-quick. I'd be happy to send you some code if you like.

[swong]

As far as performance goes, ComponentOne Graph (OletraChart) does not seem to suffer from the same performance issues. The onscreen cursor tool, dragging Marks, etc seems to work instantateously. Although you guys definately have a superior product..

I could turn off the AutoRepaint property for windows/forms that I own, but I have the same issues when other windows (ie. IE, Word, etc) touch the chart control.


Btw, I am very impressed with the level of support you guys have been able to supply me (and sorry for all the questions!)

[johnnyboyc]

Even 2 seconds seems a bit slow doesn't it? What I am trying to do is implement floating toolbars, but moving a toolbar across the chart causes a delay. The same applies to dragging Marks, etc across the graph. I have to click (an hold) for about 2-5 seconds before I can move the label.

Is there some way to stop the update of the screen until after an operation is completed (ie. after the window has been moved, etc)?

Thanks again for your prompt responses!

Surely preventing the graph from updating while you drag a window across would leave big 'trails' where the surface has been erased?

Just a thought: wouldn't it be better to provide a method whereby an internal bitmap representation of the graph could be used for quick redraw purposes? The clip area could also be determined so that you wouldn't necessarily be redrawing the entire graph... there may well be good reasons why this can't be done, but I thought I'd mention it as an idea.

[swong]

Yes, stopping it from repainting is probably a bad thing to do, but it would allow me to drag a window across the chart without having "jerk" to a stop while the control tries to redraw itself..

Anyways, that would be great if you could send me the code (although I would rather have a pure .net solution)

Thanks again!

[Marc]

Hello,

These delays do need improving upon. Improvements on current performance will be built into TeeChart, where possible, over coming maintenance releases.

Regards,
Marc Meumann
Steema Support

[Glenn F. Henriksen]

Has the performance discussed in this thread been addressed ? The behaviour appears to still be present in the latest TeeChart .NET release.

Thanks.

[Pep]

Hi,

yes, it's still present. We're working on the next release which I think will be out in a few weeks. We'll try to improve it.