custom points

[Sof]

I am using the ActiveX graph control in a C# VS2005 .net 2.0 project.  I have to use the ActiveX control because of drawing speed issues with the .net one.

I need to have custom points.  Each plot is 50 points and I need custom point annotations.  I have tried using CWAnnotations but the CWPicture is almost impossible to work with.  The image at each point must reflect the plot color so the image has to be modified and re-displayed.

The point styles that are supplied won't do, because we have to fill in the point (like a square or diamond) depending on what we call "directivity".

Is there a way to get in there and do some custom drawing on the graph?

Thanks 

[AEDavid]

Hi Sof,

What version of Measurement Studio are you using? 

What difficulties are there with CWPicture?  Perhaps I can assist.

[Sof]

MS 8.11

I would like to load in a bitmap from say, c:\image.bmp.  That's easy.  Later I would like to get that image and modify it.

I could not figure out how to get that image (CWPicture) and modify it and set it back.

[JonathanN]

Hi Sof,

I was curious as to what version of the .NET graph did you benchmark against the ActiveX graph? Were you benchmarking the Measurement Studio 8.1.1 .NET graph?

We are trying to address any performance issues people find with our .NET graph in future versions of Measurement Studio and always want to know any extra information people have.

Thanks

Best Regards,

[Sof]

We initially benchmarked against 8.1.0 earlier this year.  Recently, when 8.1.1 came out we tried the same test with virtually no improvement.

We are really glad that you are wanting to address performance issues in the .NET graph controls.  We would have preferred to use your .NET implementation without question, but the performance was very poor.  Here is an example of our test conditions:

We used the Scattergraph and plotted two arrays of 262,000 points each.  We used graph.PlotXY(xarray, yarray).  If you moved a cursor on the plot or if you resized the graph it was unbearably slow .

Using the ActiveX control, the cursor just zipped across the plot.  Resizing was a snap.

We are currently using the ActiveX control and can put up 20 plots of 262,000 points each with cursors very responsive and resizing and the like have no performance issues.  We can add more plots (as memory permits) and it is still usable with say 50 plots.  However, that's a pretty busy graph and our users typically do not put up that many plots.

[JonathanN]

Hi Sof,

Thanks for posting back and giving us some background on your applications. One major contributing factor to the difference in performance is related to the fact that the ActiveX graph uses GDI (Graphical Device Interface) and the .NET graph uses GDI+.

We are currently looking into providing WPF (Windows Presentation Foundation) support for Measurement Studio which hopefully will help address these performance issues.

Thanks and Best Regards,

[Sof]

Using GDI, GDI+, or WPF using native graphics calls (outside of NI) we have shown that the while better than your ScatterGraph, there is still a similar lag in performance.

We have theorized that the ActiveX graph is probably doing some sort of filtering on the data to minimize the number of actual graphic line draws.  When we implemented a sort of filtering we had similar performance as the the ActiveX control. 

Could you talk to your R&D guys in the ActiveX group to see what they implemented?

Message Edited by Sof on 08-21-2007 02:01 PM

Message Edited by Sof on 08-21-2007 02:05 PM

[JonathanN]

Hi Sof,

Are you comparing our ActiveX graph control to other competitors of ours that have created GDI graph controls?

I can't release any internal details of how we implemented our graph but I am glad that we are providing better performance that our competitors in that realm.

When I discuss the peformance hit in .NET, I am mostly targeting the issues customers have seen between our ActiveX graph and .NET graph.  As I mentioned, some of the limitations we have encountered are soley based off of the .NET implementation (i.e. GDI+). We are aware of this and are researching ways to boost our performance.

Best Regards,

[Sof]

No, I am NOT comparing the ActiveX graph control with other competitors!  How did you get that from my post??

We took a .NET C# app and plotted out 262,000 line segments, ie, points, using .NET GDI calls first, then GDI+ graphics calls next, and finally WPF calls third.  Each implementation was SLOW!! 

The ActiveX graph control you provide is indeed fastest by far.  This is what we are comparing; your ActiveX graph to our above native calls test.  The argument we get from NI is always that it GDI+ is the culprit.  But the above test proves that it is NOT.

The question remains, why is the ActiveX graph have such better performance than the .NET 8.1.1 graph control?  And if you can't answer that in this forum because of proprieties, then we would like you to implement this same performance in the future .NET implementation.

BTW, if you can't implement the same ActiveX graph performance in the future we would like to know that ahead of time so that we can make other arrangements.  Please email me with other info if you don't want to post that info here.

Scott

Message Edited by Sof on 08-21-2007 04:30 PM

[JonathanN]

Hi Scott,

I would like to take this issue offline. If you give me permission, I can get our web support team to provide me with your contact information so I may contact you.

Best Regards,