Re: Uninitialized array\cluster takes CPU power
> Just to show some numbers - I created a new tab control with two > pages. In the first page I put the "problem" screen (which takes 0% > when alone on the screen) and in the second I put two of these arrays > (which took 10%). If the arrays are put near the tab and the first > page is selected, the usage is 10%. However, putting the arrays into > the second page causes the usage to go to 70% when displaying the > first page, which originally took 0%. This causes me to suspect that > there is something going on with the tab control. If anyone knows, > please... If you wind up with a demonstrative program, please submit it to tech support. It is hard to rebuild these odd cases from just a description. > One last question - Greg, your answer was great, but according to what > you say, shouldn't the frame rate have been lower for the "just > grayed" array than for the "neither" one? I'd expect it to be faster too, but these were rough numbers run just once or twice without much accuracy. Also, since the data isn't changing, a nonoverlapping array doesn't need to be redrawn anyway. In reality, the array control messages the visible items with an old and new data pointer and lets them draw the minimum to "look" correct. It gets further complicated when the array is changing size or when elements are uninitialized, but without digging into specific cases. When it is overlapped, the array doesn't test all the data first, it decides to just redraw. That is why you see the big difference. For a better test case, you should have the arrays rotate or alternate. In fact adding an Invert to the 2D array guarantees every Boolean will redraw. Initialize it and test it out. Greg McKaskle
Re: Uninitialized array\cluster takes CPU power
Thank you again for your answers. First, I would like to make it clear - the only point in the VI I posted was to show the problem. I'm not using this construction anywhere and I don't plan to. Now, to the tab issue - We've now managed to identify the main problem in that program - refreshing arrays of rings 10 times a second takes a lot of resources when they're partially visible. We've changed that and now it's working fine. However, this doesn't change the fact that this problem also happened when these arrays were on non-visible pages of the tab control and would only go away when the arrays were completely moved off the screen. Just to show some numbers - I created a new tab control with two pages. In the first page I put the "problem" screen (which takes 0% when alone on the screen) and in the second I put two of these arrays (which took 10%). If the arrays are put near the tab and the first page is selected, the usage is 10%. However, putting the arrays into the second page causes the usage to go to 70% when displaying the first page, which originally took 0%. This causes me to suspect that there is something going on with the tab control. If anyone knows, please... BTW, I'm not sure how important this is, but I was told this program was converted from LV RT 6.1, where it was said to have worked fine. One last question - Greg, your answer was great, but according to what you say, shouldn't the frame rate have been lower for the "just grayed" array than for the "neither" one?
Re: Uninitialized array\cluster takes CPU power
> Thank you all for your answers. They've been very helpful in > understanding the problem. I understand that refreshing the screen is > hard and I know that LV requires a lot of resources but still - we're > talking about 10 FPS - that's not a fast refresh rate. In response to > Shea's question, we have a few programs in which such constructions > exist. Bad programming practices? Maybe, but I still think a modern > computer should be able to handle this task. Anyway, from now on I'll > try to avoid doing it, if possible. > P.S. Shea - I understand what you're saying about local variables, but > I'd still expect most programs to have quite a few of them. You already have quite a bit of info in this, but I can explain a bit more. All controls in LV will take longer to draw when overlapped, but the LEDs you are using are even more expensive as the bezel or divot is actually a blend with the objects beneath, and that requires several steps to draw. Add to this the fact that they are grayed out after drawing, which is another blend action. By initializing the array, you get rid of the blend with gray. Here are the numbers I gathered by deleting your delays and running all out on my computer. Covered, grayed, I got 26 FPS Just grayed I got 500 FPS Covered, but not grayed, I got 36 FPS Neither, I got 480FPS And I think others mentioned this, but if the point is to have LEDs around the big button, make a cluster instead with 32 buttons and a big button in the middle. You won't have overlapping. Finally, I just wanted to point out that it isn't reading the array, but writing to the array that causes the redraws. Greg McKaskle
Re: Uninitialized array\cluster takes CPU power
Thank you all for your answers. They've been very helpful in understanding the problem. I understand that refreshing the screen is hard and I know that LV requires a lot of resources but still - we're talking about 10 FPS - that's not a fast refresh rate. In response to Shea's question, we have a few programs in which such constructions exist. Bad programming practices? Maybe, but I still think a modern computer should be able to handle this task. Anyway, from now on I'll try to avoid doing it, if possible. P.S. Shea - I understand what you're saying about local variables, but I'd still expect most programs to have quite a few of them. Thanks again for your answers.
Re: Uninitialized array\cluster takes CPU power
Hello tst, Thank you for your inquiry regarding CPU usage when using an array covered by a control. After running the VI I understand the problem that you are having and this problem does exist in standard LabVIEW 7.0. It takes a lot of resources to update a front panel when controls/indicators are layered on top of each other. I=92m not sure exactly in what situation you might need to place controls on top of each other and I assume that you need all of the features that you mentioned resolve the problem. One possible solution would be to rid the VI of the =93Array=94 local variable. This seems to speed up the update rate and solve your problem. Typically variables and especially global variables seem to slow down performance. The following link is one resource when troubleshooting this behavior. http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=3D101&RPAGEID=3D135&H= OID=3D50650008002751&UCATEGORY_0=3D_49_%24_6_&UCATEGORY_S=3D0&U= SEARCHCONTEXT_QUESTION_0=3DVertical+Slider+Control+%28Classic+Control%29+ta= kes+50%25+of+CPU+Time+when+Loaded+in+Memory+Only&USEARCHCONTEXT_QUESTION_S= =3D0 Other responses similar to this can be found on the ni.com website by clicking the support tab at the top of the home page. Then search for =93Memory and CPU usage=94 from Technical Resources at the top of the page. I hope these resources help. Let me know if I can further assist you. Shea C. Applications Engineering
