Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

Moving the IntensityGraph cursor freezes out all other form activity

Hello, I'm running into a problem using a cursor in an IntensityGraph. I have a .NET C# WindowsForm with a SplitContainer, one of the container's panels has a ScatterGraph and the other panel has an IntensityGraph. Each graph has a cursor. When the ScatterGraph cursor moves, no problems there. However, when the IntensityGraph cursor moves, this locks out all other activity (e.g. any updates to the plot data to *either graph*) until that IntensityGraph cursor is no longer moving. The entire form appears to 'freeze' as long as the IntensityGraph cursor is moving. Again, when I move the ScatterGraph cursor, it has no effect on any other form controls - e.g. any real-time plot updates to either graph work fine.  Any idea as to why moving the IntensityGraph cursor causes this behavior? Can you suggest any workarounds?

 

This is Measurement Studio 2010 on Windows XP.

0 Kudos
Message 1 of 18
(4,576 Views)

Hello there,

 

Can you please attach a simple project that would reproduce this issue? This would be very helpfull in identifying the issue you are facing and will help us in guiding you in the right direction.


Thank you,

 

Vijet Patankar,

National Instruments.

0 Kudos
Message 2 of 18
(4,567 Views)

Hello, I found that placing any control over the intensity graph freezes out updates to all NI graphs on the form while that control is moving. I put a simple label over the intensity graph plot area, and when I move it (by implementing mousemove event such that label follows mouse movement) it freezes the plots in both scattergraph and intensitygraph on the form. Can you tell me why this happens? Is there any reason to think such behavior could be 'fixed' in the MStudio 2012? (I'm still using MStudio 2010).  Would really like to get this problem resolved. Thanks.

0 Kudos
Message 3 of 18
(4,532 Views)

Hi jble,

 

When you place controls on top of each other, you run into an issue of redrawing more than necessary. Now instead of redrawing objects independantly, the software will have to update both on every redraw event which can slow down performance.

 

If you can, post a sample project as Vijet mentioned.

 

Cheers,

KyleP
Applications Engineer
National Instruments
0 Kudos
Message 4 of 18
(4,521 Views)

OK, attached is sample project. Move the mouse in scatter graph at the top. When intensity graph cursor is not visible, graphs are fine. When intensity graph cursor is visible, moving the mouse in scatter graph freezes the graph updates.

0 Kudos
Message 5 of 18
(4,516 Views)

Hi jble,

 

I'm assuming that the event that is fired is locking up the rest of the panel updates. It looks like the scatterGraph1_PlotAreaMouseMove method is being called so rapidly that intensityGraph1 doesn't have time to update. Would it be possible to tie the method to an event other than the mouse moving on the screen? A user mouse click would free up processor time since it would be called less often.

 

Cheers,

KyleP
Applications Engineer
National Instruments
0 Kudos
Message 6 of 18
(4,494 Views)

Thanks for the suggestion, but the whole point is to provide a dynamic cursor that tracks mouse movement, so a 'click' event wouldn't work here.

 

It sounds like the root cause of this problem is the slow-ness of the intensitygraph updates. Does this reflect something fundamental about the intensitygraph implementation? Is there anything that can be done to improve the speed of intensitygraph updates so that they are more on-par with the scattergraph performance? There isn't any issue with moving a cursor in the scattergraph.

 

0 Kudos
Message 7 of 18
(4,491 Views)

Hi jble,

 

I spent some time working with a colleague on this issue and we came up with a solution. I'll paraphrase his email a bit:

 

Instead of using System.Windows.Forms.Timer to handle the timing, I used System.Timers.Timer with the SynchronizingObject set to the form. System.Timers.Timer runs asynchronously, but the SynchronizingObject specifies which thread the tick event handler (called Elapsed event for this timer) is ran in. Setting this to the Form is important because you are not supposed to access UI objects outside the thread that instantiated them. It would seem that setting the SynchronizingObject to the form would be the same as just using the timer, but there is a subtle difference in the behavior that is well described in this article, quoted here:

 

When the operating system notifies the System.Timers.Timer class that the enabled timer has elapsed, the timer uses the SynchronizingObject.Begin.Invoke method to execute the Elapsed event delegate on the thread on which the SynchronizingObject's underlying handle was created. The event handler will be blocked until the UI thread is able to process it. However, unlike with System.Windows.Forms.Timer, the event will still eventually be raised. As you saw in Figure 2, System.Windows.Forms.Timer will not raise events that occur while the UI thread is unable to process them, whereas System.Timers.Timer will queue them to be processes when the UI thread is available. 

 

So as you can see, the Windows Forms timer was not generating events while the cursor updates were being processed. 

 

Please see the attachment for the revision to your code.

 

Cheers,

KyleP
Applications Engineer
National Instruments
0 Kudos
Message 8 of 18
(4,465 Views)

Appreciate your taking the time to research the issue and propose a solution.

 

I tried your suggestion of using System.Timers.Timer instead of System.Windows.Forms.Timer. It worked, but unfortunately the change had side effects that caused other problems in my application.

 

However I was able to find an alternate solution that works for us. Attaching an updated example project.

 

I'm still not happy about the performance of IntensityGraph paint(). I presume this is the root cause of why the System.Windows.Forms.Timer timers were not firing in the original project (i.e. the UI thread was always busy painting the IntensityGraph plot). Currently this problem is limiting the amount of data we are able to display in our application -  it's less than half what we really need to display. I noticed there's another recently created thread on IntensityGraph performance. Are the developers aware of this problem, and is this something that can be addressed in future versions of MeasurementStudio? Thanks.

0 Kudos
Message 9 of 18
(4,455 Views)

Hi jble,

 

Thanks for taking the time to post your updated code. I can assure you that in this particular case, someone from our development team is aware of this thread. Also, for future reference you can post product suggestions to the Measurement Studio Idea Exchange. Popular posts in that forum should get the proper visibility.

 

I'm glad that you were able to find a workable solution.

 

Cheers,

KyleP
Applications Engineer
National Instruments
0 Kudos
Message 10 of 18
(4,438 Views)