LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Overlapping Front Panel Objects

Solved!
Go to solution

I understand that overlapping front panel controls (booleans, numerics, plots, etc.) will cause a significant update penalty.  What about using tab structures or decorations from the modern/classic pallete (such as raised block, recessed block, frame, things like that)?  Will this cause a severe penalty in processor time?

--------------------------------------------------

Nathan - Certified LabVIEW Developer
0 Kudos
Message 1 of 6
(3,837 Views)

Am not sure what do you mean by Overlapping controls? Is it simply placing a control over another control?


@Nathan_S wrote:

I understand that overlapping front panel controls (booleans, numerics, plots, etc.) will cause a significant update penalty.  What about using tab structures or decorations from the modern/classic pallete (such as raised block, recessed block, frame, things like that)?  Will this cause a severe penalty in processor time?


Tab structure is meant for accomodating different set of controls in a single place as pages but decorations are different and you cannot control them through the code.
If you can be more specific then you would get a straight forward answer.
-----

The best solution is the one you find it by yourself
0 Kudos
Message 2 of 6
(3,827 Views)
Solution
Accepted by topic author Nathan_S

Natan,

 

Any stacking of objects will cause a performance hit.  Now, depending on your program, it may not be a big deal.  I did a bit of work with this several years ago, so I am assuming not much (basics, at least) has changed.

 

LabVIEW basically draws from the bottom up, so whatever you have stacked, the bottom element is drawn, then the one above it, etc.  Although I do not know for sure, I expect this happens within the control as well.  For example, a numeric control has several layers to it.

 

When I did all my work, I saw a tremendous hit on performace without too much stacking.  The test time was 3:30 with th UI I created.  If I did not display the UI at all, I knocked over 45 secs off the test test.  With simnplifying the UI, I think I knocked about 30 secs off.

 

What I also found is that the quality of your graphics chip has significant effects.  I was testing with the second model of the PXI controller (this was maybe 12 years ago),  I could outperm the PXI controller with a low end PC using MXI because it had a dedicated graphics card that handles the UI updates much faster than the PXI controller.

 

 

Message 3 of 6
(3,812 Views)

I wasn't sure if static objects (i.e., not control objects) that didn't change would be redrawn.  From what I gather, even using a Tab structure would cause a performance hit?  It seems like natives like that wouldn't hurt execution, maybe I'm just not seeing something here.

--------------------------------------------------

Nathan - Certified LabVIEW Developer
0 Kudos
Message 4 of 6
(3,801 Views)

It's just the method LabVIEW uses to update the screen.  It doesn't matter what it is, when it comes to updating the screen, its just pixels.  I would have thought there would have been a fiarly easy way to know what areas of the screen are stacked and only do the update on the top, but perhaps that is way more complicated than it sounds.

0 Kudos
Message 5 of 6
(3,793 Views)

Improve Performance in a Front Panel with Many Controls and Indicators

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kHjFSAU&l=en-GB

0 Kudos
Message 6 of 6
(2,523 Views)