> 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
