Re : Re: 2D Graph control speed issue using Windows 2003 Terminal Services

[Eric_B]

Hi,

I've designed an ActiveX control that display multiple trends in a HMI interface. I'm usign Measurment Studio for Visual Basic 6 (v8.0) 2D Graph control control (from cwui.ocx) to do the graph rendering. So I'm using Measurement Studios' ActiveX control in my own ActiveX control that is loaded by the HMI software.

This HMI application runs on a Windows Server 2003 HP Server with Terminal Services and is accessed by several ThinClient computers (i.e. computers with no "real" OS on them. They only connect to the Terminal Server and display a session from it). The server itself is quite powerfull. It's an HP Proliant DL-380 Dual Processor (2x 3.2 gHz Intel Xeon processor) with 4Gb of RAM.

The HMI application itself is runing at a screen resolution of 1600 x 1200. If I run the application from a standalone computer, everything is working fine. But if I run the application on a ThinClient from the Terminal Server, the 2D Graph control becomes really slow. Especially when I try to move (drag) the entire plot area of the graph or when I move the cursor on it (a vertical cursor on the graph which dispays).

I was wondering if anyone knew ways to make the render of the graph faster on Terminal Services? We've tried with several types of ThinClients (from a 400mHz to a 1Ghz, all of them with 100Mbit Ethernet card) and the speed seems to be similar on all of them. So we're now trying to optimise our ActiveX so as to lower the amount of graphical data send to the ThinClient.

The HMI Software we're using is Invensys' WonderWare InTouch 9.5 SP2, running on Windows Server 2003 Enterprise SP1. I'm using version 8.0.11.318 of the cwui.ocx control and Visual Basic 6 SP6 to desing my ActiveX control. For our ThinClients, we're using ACP ThinManager 3 and the Windows RDP Protocol (not the Citrix one). All ThinClients are running at a screen resolution of 1600 x 1200 in 15bit color depth (specified directly in the RDP protocol, not on the ThinClients themself). We've tried running the application in 8 bit color depth (256 colors). It did imporve the speed of the 2D Graph control a bit, but not enough. And it wasn't doing a good job on the overal look of the HMI...

Thank you very much.

Eric Brousseau

Software Developer

AIA Automation Inc.

[DWeiland]

Hi Eric,

There's a couple of things you could try adjusting to affect the performance of your graphs. You can trying changing Chart Style and Chart Length to change the manner in which the ActiveX control is updating, as well as change between the Plotting and Charting methods of displaying your data.

Also, you mentioned that you were creating an ActiveX control. I don't know how effective this document may be for you, but I've found it useful in the past:

http://www.fawcette.com/archives/premier/mgznarch/VBPJ/1999/08aug99/fb0899.pdf

One last thing - try running one of our Measurement Studio shipping examples on your HMIs to determine whether or not it's something specific to your application and the manner in which you are using the CWGraph control or if it's the CWGraph control itself.

Thanks Eric, let us know what you find.

[Eric_B]

Hi,

Just to make sure you understand exactly the problem I'm getting :

The CWGraph control works great when updating it's value (i.e. when I get new values to plot) but the problem I'm getting is with the display of fixed, existing data.

If I put my control in history mode (so that it doesn't update itself with new data) and then I do CWGraph.TrackMode = cwGTrackPanPlotAreaXY and then I move the plotted data around with the mouse, the refreshing of the display becomes really slow. It kind of "lag" behing the motion of the mouse. I also get the same problem with CWGraph.TrackMode = cwGTrackDragCursor. The cursor "lags" a lot behind the mouse. In both case, I can get up to 2 seconds of that "lag" between the moment I release the mouse button and the moment the graph (or the cursor) stops moving. And also, the amount of that "lag" isn't always the same. It "seems" to be dependant on the amount of "drawing" shown in the graph (i.e. a graph with flat lines doesn't "lag" as much as a graph with lots of spikes) so it might have something to do with the way TerminalServices refreshes the display of it's clients. And also, as I said in my original post, the control works fine on a regular PC when it is run locally.

So It's not related to how the CWGraph control render it's data (since the CWGraph.ChartXY method isn't called during the dragging of the display) and also the graph doesn't plot "new" data, it re-plot the entire graph on each "refresh" since the data stored in the archiving system is being compressed and mignt change over time because of that. By the way, should I use ChartXY or PlotXY in this case if I want to keep only the last set of data I got in the CWGraph buffer?

And also, I plot 2 times as much data as it is needed to render the full graph. I put half of the "spare" data on each side of the graph so that when the user drag the plot area around, it sees some data on each side and I do a full refresh when it release the button. And even better, the API I use to access the archiving system has a special function to get data for graph rendering. It return only the amount of points needed to render the graph based on it's width in pixels (it returns up to 5 points for each pixels (if they are differents) : min, max, start of period, end of period and one more point if needed to better represent the "average" value of the period) so I always have more or less the same amount of points in my graph (1450 pixels * 2 times the width * 5 points = 14500 points, which is the value I've set ChartLenght to)

As fot the testing of one of your examples in our HMI, I might give it a try this week to see how it will react. I'll give you some feedback on it when I'll be done.

Thank you and good day,

Eric Brousseau

AIA Automation Inc.

[Eric_B]

One more thing,

We've done some more testing on the control yesterday and we've found something:

When we get the "lag" problem on the control, the CPU load of the Terminal Server goes up to 100%. We use a 2.8 gHz Pentium 4 with Hyperthreading and 1 Gb of RAM for our tests and we've started 2 ThinClients running our HMI software. We've then set each of the HMI process (one for each client) to run one on each virtual CPU (with Hyperthreading, Windows sees your physical CPU as 2 virtual CPU unit) and we've started playing around with the control on the ThinClients. Then the CPU load went up to 100% on each of the virtual CPU. Both CPU were completely loaded by our HMI processes.

So we were wondering if this could have something to do with the amount of visual data generated by the control. Since all graphical rendering must be done by the software on the server for each of the ThinClient and then be sent to the ThinClient as bitmaps. We were wondering if anything could be done to "slow down" the rendering of the control. Maybe only rendering the content when the mouse stops moving for 250 ms or rendering 1 frame every 250 ms. We would rather have a choppy moving graph than a laging one.

Any idea would be welcome.

Thank you,

Eric Brousseau
AIA Automation Inc.

[AndrewMc]

I do not know of any way to specify a rendering rate slower than that of the default, but I will check into it and let you know if I find something out.

[AndrewMc]

I talked with R&D, and it is not possible to set a lower refresh rate for the graph.  When developing, R&D looks at what refresh rate is the best for visibility to the naked eye, but that value is not reconfigurable.  Sorry for any inconvenience.

[Eric_B]

Hi,

We've done some more testing here. And we've found some new infos.

First of all, the CWGraph control really eats up CPU power when you move a graph around or when you move a cursor over it. I've made a standalone EXE in VB to test our ActiveX without the container application (our HMI). I've copied my ActiveX content and code into that application and I've tried to run it on our TerminalServer setup. This application uses as much CPU power (i.e. all of the available CPU power) when I move the graph around as the ActiveX control did in our HMI software. It was doing so when we ran it locally on the server as well as when we ran it on the ThinClient (but the rendering of the graph isn't choppy when running it locally). Is it normal? And to do some comparing, I've designed a simple application in VB.Net to try the .Net version of the control (the WaveformGraph control) and it uses around as much CPU power as the VB6 version of the control. Isn't it a little CPU intensive, especially if you intend to run multiple instances of an application on the same computer?

Another important point we've found out is that if we reduce the size of the ActiveX shown on the screen, the amount of "lag" becomes much smaller. The ActiveX control I've designed cannot really be "resized". If you change it's size, you're only hiding part of it. So the problem might not entirely be related to the amount of rendering the control itself is doing. It would also seems that the Microsoft RDP protocol is having difficulties sending all of the graphical data out to the ThinClient.

So the same basic question remains : How could I reduce the amount of visual data sent to the ThinClient without reducing the size of the control on-screen?

Thank you,

Eric Brousseau

AIA Automation Inc.

[AndrewMc]

Hey Eric,

It is understandable that the Microsoft graph exhibited the same behavior.  The Measurement Studio graph is actually less processor-intensive than the Microsoft Graph.

I was able to locate a property that might help you.  The Component Works Graph class has a property called ImmediateUpdates.  If this property is set to false, the graph will use the same update rate that the form uses.  Additionally, there is a method called Refresh in which you can manually update the graph. 

Hopefully with the these ideas, you might be able to get it working.

[Eric_B]

Hi,

The ImmediateUpdates property was already set to false in my control. But the Refresh method gives me an idea: Is there a way to control the refresh of the graph entirely with this method? If so, I could manually control when the graph refresh itself and I could fine-tune it better for my TerminalServer setup.

So, is there a way to completely disable the automatic refresh on the CWGraph control, even when CWGraph.TrackMode = cwGTrackPanPlotAreaXY?

Thank you.

Eric Brousseau

AIA Automation Inc.

[AEDavid]

Hi Eric,

1. I googled, checked MSDN, and spoke with R&D, and there does not seem to be any way to disable updating forms.  ImmediateUpdates will disable updates when the control changes, but it will still automatically update when the form updates. 
   
2. We can update the graph manually by using the Refresh Method.
3. Since Microsoft graphs exhibit the same behavior, this problem does not seem to be unique to NI controls.  Rather, it seems to be with the underlying design of Visual Basic.

Some suggestions are:

• continue decreasing the chart length.
• change the chart style (using a strip chart).

Message Edited by AEDavid on 10-31-2006 02:14 PM