CWGraph and gpu interaction

[antadam]

I'm curious as to finding information about the graphics cards and controlling redrawing of multiple cwgraph instances.

At the moment, I'm developing an application w/vc++ mfc 7.1 w/measurement studio 7.0 using the cwgraph to display information as it comes off the serial port in real-time. Everytime 50 points are stuffed into a CNiReal32Matrix, I graph those next 50 points. At the moment there is 1 thread for each graph which posts the memory location of a CNiReal32Matrix instance to each of the 2 cwgraph instances we have at the moment.

When it comes to drawing the information on each graph, this application seems to perform slowly on a tablet pc running at about 1.1 ghz w/a somewhat poor graphics card (win xp sp1). I'm questioning
the cwgraph control as the similar version of the application for labview runs with no problems what so ever where both graphs stream the real-time data in perfect sync. There are no real functional differences between these 2 programs. The dual graphs almost run out of sync even when running on a 2.4 ghz p4, w/1 gig of ram, and a 256 meg ddr radeon 9600.

I'm currently exploring a few other options as to where this bottlneck may be occuring, however, this is one of my last points to research when it comes to this problem. I'm hoping someone on out there can provide me/point me towards some helpful documentation so I can find my bottlneck.

TIA,
Adam

[drohacek]

Adam -

There are a few things you can try to boost the performance of the graph.

1) Turn off the 3D frame. The 3D drawing impacts performance. Go to Properties>>Style and uncheck 3D Frame.

2) If you are using a ChartXY or ChartXvsY method, minimize the size of the chart history that each graph maintains. If you never need to scroll back through the data, you should reduce the chart history length to only what you want to display. If you are using ChartY, set the Chart history to automatic (Properties>>Graph>>Chart history).

3) If you are calling plot methods on the CNiPlot object rather than on the CNiGraph object, cache a reference to the CNiPlot object instead of repeatedly accessing it through the CNiGraph::Plots property. Accessing through the C
NiGraph::Plots property results a few calls into the control, which slows performance.

4) If possible, create each graph in the thread from which you will be accessing it. The issue here is that all calls into an ActiveX control must occur on the thread that creates it. The Measurement Studio C++ classes use the COM Global Interface Table (GIT) to automatically work around this limitation for you. The effect, however, is that calls to the graph and its subobject from a thread other than the thread that created it result in the call being serialized as a windows message and posted to the thread that created the control. This means that if you create both graphs on the user interface thread, all calls to them will end up occurring on the user interface thread. If you do create the graphs on different threads, you can pass CNiInterface::SingleThread to the graph constructor to elimin
ate the overhead caused by the control using the GIT.

Let us know how these options work for you or if you need more information about dynamically creating a control in another thread.