Loop slows down when certain parts of screen are active

[Sima]

Hi, I've noticed that one of my loops, which is set to run at 50ms, slows down significantly when certain other parts of the screen are active.

We have a dual screen setup where on the left side we have a bunch of controls and I'm also displaying the time that 50ms loop takes. On the 2nd screen, there is a tab control with several pages. When some of the pages are displayed (and those are the ones that are probably the "busiest" in terms of processing), the loop time slows down to anything in the range of 1-4 seconds.

The loop runs at 50ms when other lower-processing tabs are showing. It will also run at 50ms when any other window (another VI, another application) is hiding that right tab display. Actually, it'll run at 50ms if another window hides about half of that right tab 😄

What can I do to be able to watch those tab pages and keep my loop running from slowing down? One of those tab pages is a fault message display, so it's good to watch while you're running a test!

Thanks.

[Ben]

It sounds like defer front panel updates may be helpful.

It will delay the actual updates of the display but will accumulate all of the updates (behind the scenes) until updates are "un-defered".

Ben

Message Edited by Ben on 04-28-2006 01:59 PM

[tst]

I would start by checking what you're displaying in your pages. You might be doing something that doesn't need to be done all the time.

I once ran into an issue where screen updates to a control in a tab would slow down the computer (100% CPU usage) even when another tab page was selected and would only stop when the tab was moved off the screen or when the control was moved out of the tab. Unfortunately, I was never able to reliably recreate that issue. In that case the problem was with updating the strings in an array of rings using a property node, but yours might be a different case.

If what I described sounds similar to what you're seeing (increased CPU usage even when the real culprit is not displayed) I would be interested in seeing a demo.

[Evan]

Something to look at would be overlapping controls and any transparent controls.  The controls bounds are defined by the "ants marching" not what you may expect the size to be.  So if you change the value of an overlapping control they both may need to re-draw.  The over lap may simply be a pixel on the borders of the controls.

If you can attach a mock-up we can also try to narrow it down.  However, trimming your code down may make it a non-issue so.....

[Sima]

Thanks for your replies.

tst, it certainly was those rings and arrays of rings... 6 stars for you! 🙂 I don't like to use property nodes much, but that's the only way I know how to fill a ring - and rings make the interface nicer and a little less foolproof for the user, etc.

Originally, I had all the property nodes for those rings in one slow loop, but I guess that wasn't enough, so I just made them refresh on change (tsk tsk, should've done that to begin with). I was able to speed up my higher-importance 50ms loop even more, and the CPU usage calmed down as well. Thanks again!