Uninitialized array\cluster takes CPU power

[Greg_McKaskle2]

> 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 con
trols 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

[tst]

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?

[Greg_McKaskle2]

> 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 an
swer 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