You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We generally don't want this kind of node graph stuff to trigger potentially expensive computations without deferring to a background thread ... but currently DotNodeGadget::plugDirtied just calls updateLabel(), which does a getValue() on the label.
This getValue() doesn't scope the script's context however, resulting in inconsistent results - if you drive a Dot's label with an expression that depends on context, you see one value in the Node Editor and a different value in the Node Graph.
It should be pretty easy to scope the script context, but once we're allowing for computation to happen here, maybe we should also be deferring this to a background thread at the same time?
The text was updated successfully, but these errors were encountered:
Fixed in #5332. We should move stuff to a background thread at some point, but since we're already paying the cost of a compute, we might as well do the right compute.
We generally don't want this kind of node graph stuff to trigger potentially expensive computations without deferring to a background thread ... but currently DotNodeGadget::plugDirtied just calls updateLabel(), which does a getValue() on the label.
This getValue() doesn't scope the script's context however, resulting in inconsistent results - if you drive a Dot's label with an expression that depends on context, you see one value in the Node Editor and a different value in the Node Graph.
It should be pretty easy to scope the script context, but once we're allowing for computation to happen here, maybe we should also be deferring this to a background thread at the same time?
The text was updated successfully, but these errors were encountered: