Should All Property Nodes go through UI thread?

[Pnt]

Every Property Node causes a switch to the UI thread. This causes many vis to run quite slowly, if they make extensive use of property nodes. My question is: should there be, a user defined option, to choose if the property node will cause a switch to UI ?

In other words, a kind of local variable. There are many properties, like changing the color of a text, which are not time critical.

Disadvantages: this would cause a control copy in memory, and possible race conditions.

Advantages: For small controls the data copy would have no impact in memory, and the code would execute much-much faster, as there would be minimum switches to UI thread. The update of the controls would take place like the local variables.The possible race conditions would be the users responsibility to handle. (like local variables).

Is this a reasonable request ?

[David_B]

Hi Pnt,

This seems like a valid product suggestion.  I've been perusing the forum today and noticed a number of other users running up against the same thing.

Feel free to visit our Product Suggestion Center in order to submit that suggestion.

[Ben]

" Should All Property Nodes go through UI thread? "

I don't think I would like the results of all of the overhead that would be required to manage GUI updates if this option was available.

THe UI Thread was chosen since it is single threaded and therefore all activity in that thread have to run sequentially.

If you really need to increase the spead of updates to FP objects then you could

A) set the VI that performs the updates to run in the UI thread (preventing a switch for each poperty node)

B) Defer Front Panel updates before peforming the updates.

The above does not take into concideration that all of those properties can be invoked from other software via ActiveX where even more contention is possible.

That's just my 2 cents,

Ben

[Pnt]

Ben

I don't think the overhead you mention, will be significant. For example take the local variables. For small amount of data, they are way more faster than property nodes (property node: value).  

The mechanism for update front panel exists (local variables), they could just add the property nodes.

The solutions you suggest, assums that the property nodes can be gathered all together. The way, i suggested above, can be implimented without additional coding for the user, just right clicking on a property node.

Of course i am not a NI engineer.... just a thought i had...

Thanks both for the replies

Message Edited by Pnt on 02-27-2008 08:40 AM

[rolfk]

---

@Pnt wrote:

Ben

I don't think the overhead you mention, will be significant. For example take the local variables. For small amount of data, they are way more faster than property nodes (property node: value).  

The mechanism for update front panel exists (local variables), they could just add the property nodes.

The solutions you suggest, assums that the property nodes can be gathered all together. The way, i suggested above, can be implimented without additional coding for the user, just right clicking on a property node.

Of course i am not a NI engineer.... just a thought i had...

Thanks both for the replies

Message Edited by Pnt on 02-27-2008 08:40 AM

---

First, not all property nodes force a UI thread switch. For properties of user interface objects of course this is true. Also for some VI Server functionality in general such as Open VI Refnum and such to avoid race conditions in the implementation of those functions.

Second what you propose with the copying of the properties into an intermediate location like for local variables would require a complete shadowing of the entire hierarchy of each object. This would be a real waste of memory, rather complicated to do and cause runtime delays too as the UI thread would have to visit huge changes lists regularly to copy data from the shadowing memory into the actual control. And not to mention the potential problem of reading those properties back: would you rather see the actual state on the front panel being returned or the proposed state in the current shadow location if any?

Also the real big delay is not so much in the thread context switch as much more in the actual drawing of a control on the screen. Using Defer Panel Updates during application of a huge number of control property modifications is much more likely to give you considerable speed improvements. Also make use of the expandable nature of the property nodes. A single property node will update all its properties before triggering the actual control update on screen so it's obvious that a single property node updating 10 properties is likely to be close to 10 times faster than 10 individual property nodes scattered through your diagram. That the UI thread switch will also only happen once instead of 10 times will help a bit too but the most time saving will be in the one time control redraw compared to the possible 10 times control redraw. Using Defer Panel Updates has in principle the same effect althought the UI thread switch will of course occur for each property node.

Rolf Kalbermatter

Message Edited by rolfk on 02-27-2008 09:52 AM

[Pnt]

   Rolf wrote:

   not all property nodes force a UI thread switch. For properties of user interface objects of course this is true

---

Does this mean that property nodes, for objects that are not visible executes really fast, as their is no drawing, and no switch to UI thread ?

[rolfk]

---

@Pnt wrote:

@   Rolf wrote:

   not all property nodes force a UI thread switch. For properties of user interface objects of course this is true

---

Does this mean that property nodes, for objects that are not visible executes really fast, as their is no drawing, and no switch to UI thread ?

---

If you mean with not visible, objects that have been hidden: No! If you mean objects that have no UI component in any way (the ominous scripting) then I believe yes sometimes. For VIs for instance that is not a trivial thing to answer. Since it has a visible front panel, and also interfaces with the excution system which needs to be protected from race conditions too.

Rolf Kalbermatter

[Larry_Stanos]

Rolf was previously correct when he stated that  "A single property node will update all of its properties before triggering the actual control update on screen" for older versions LabVIEW 8, but  in LabVIEW 8.5.1 I am now finding that every property changed in a single property node triggers a control update on the screen.  Specifically, I have observed that setting the XScale.Minimum, XScale.Maximum, YScale.Minimum, and YScale.Maximum properties in a single XYGraph property node results in not one, but four, screen refreshes, dramatically hurting performance in a 15-step "zoom" operation I programmed.  What used to be a smooth zoom-in effect, is now a slow, choppy, disorienting effect as each scale parameter is changed in sequence 15 times.

I know that a workaround is to insert a Defer Panel Updates vi property node before and after the xygraph property node, but this adds considerable clutter to my code and I hope that the behavior of property nodes will be restored to their previous behavior in a future release.  Does anyone know whether the undesirable behavior persists in 8.6?  I didn't see this mentioned in the list of fixes.

Larry Stanos

[Ben]

---

Larry Stanos wrote:

Rolf was previously correct when he stated that  "A single property node will update all of its properties before triggering the actual control update on screen" for older versions LabVIEW 8, but  in LabVIEW 8.5.1 I am now finding that every property changed in a single property node triggers a control update on the screen.  Specifically, I have observed that setting the XScale.Minimum, XScale.Maximum, YScale.Minimum, and YScale.Maximum properties in a single XYGraph property node results in not one, but four, screen refreshes, dramatically hurting performance in a 15-step "zoom" operation I programmed.  What used to be a smooth zoom-in effect, is now a slow, choppy, disorienting effect as each scale parameter is changed in sequence 15 times.

I know that a workaround is to insert a Defer Panel Updates vi property node before and after the xygraph property node, but this adds considerable clutter to my code and I hope that the behavior of property nodes will be restored to their previous behavior in a future release.  Does anyone know whether the undesirable behavior persists in 8.6?  I didn't see this mentioned in the list of fixes.

Larry Stanos

---

Hi Larry,

This is the first I have heard about this changed behaviour.

Would you please provide a stripped-down example that demonstrates your observation?

If what you have reported is true, I , we,  EVERYONE would like to see that fixed ASAP.

Ben

[Larry_Stanos]

Ben,

Attached is a vi demonstrating the issue with multiple front panel updates triggered by a single control property node.

Larry