Do running VIs with a closed front panel use CPU for UI elements?

[MarkCG]

Say you have several  VIs that you are inserting into a subpanel display as pages, as an alternative to making them pages of a tab control.  Say those pages each have I don't know something that requires more than average CPU to draw like an X-Control that's getting updated a decent rate. Does LabVIEW use resources to redraw each of those diplay elements if the front panel is closed in this situation? 

[hooovahh]

I don't have a link to someone at R&D claiming this to be so, but I know that some amount of resources are freed up by not showing the UI, this includes even minimizing the window.  Now the question remains is there some amount of system resources being used up by a UI not being seen and it is just much less than if the UI is normally shown?  No idea and some testing would be needed to know.  In extreme cases I do things like write code which keeps track of which UI is being shown, and if it isn't, then to not go into the state in the state machine that would update the UI.  I've also done this with tab controls where I know I don't need to update the controls in a tab if that tab isn't being shown.  Even so I think the most common case for CPU usage on a UI is a graphs with many data points, or very large MCLB with individual cell coloring or properties, and not for individual scalar controls.

[MarkCG]

thank you, I am trying to get some more insight into what happens under the hood. I have noticed some cpu spiking behavior when switching between tabs of a tab control on a cRIO embedded UI which actually caused a scan engine timed loop to miss. Not important as far as the application was concerned but it got me me thinking on how to exert more control on what the UI is doing. 

[Rolf Kalbermatter]

In terms of CPU there is definitely less resource consumption by an invisible control, quite independent on how it was made invisible (made invisible, on an invisible tab, window minimized or hidden). In terms of memory resources there is not really any difference, the control still is there and needs to manage its state and data. This also means that it is not 100% idle. If you change properties, or the value in any way, it will take some processing power to update the internal state of the control even if it is invisible. However this is typically significantly less of an effort than even just updating a single numeric control on a front panel. YMMV of course, updating a graph with a multi mega samples array will take some time as the data may have to be copied into a new data buffer, but the drawing of invisible controls is postponed until they get visible again (if LabVIEW knows that the control is invisible, that might be different for a control that is on a technically visible panel but outside of the bounds of your screen).

Edited August 29, 2017 by rolfk

[hooovahh]

Thanks rolfk for saying what I was thinking.  That being said if we are talking about a cRIO with an embedded UI thing in theory things work the way you described, but I simply haven't heard enough from other developers, and haven't had enough experience with it to say one way or another if it behaves differently.  YMMV indeed.  If you are seeing some reproducible issue I'd ping NI on it.  It is possible there is a bug in some UI behavior, or optimization that could be made.

[JamesMc86]

I would guess that switch tabs means that everything on that tab is now triggered to be redrawn (which would be inline with rolfk's comments). If you had some large graphs or something similar then reducing the data they are holding may help reduce the spike to an acceptable level.

That said the embedded UI is new and has a few... quirks... so if there is nothing big then talking to NI might be worthwhile as it could be a bug.