-
Notifications
You must be signed in to change notification settings - Fork 635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix crashes by undoing/redoing nodes deletion #11021
Changes from all commits
890abfc
ce20111
01cf77f
67477ab
669d288
0c4fc28
acb0cd1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -666,12 +666,15 @@ private void Model_AnnotationsCleared() | |
|
||
void Model_NodesCleared() | ||
{ | ||
foreach(var nodeViewModel in Nodes) | ||
lock (Nodes) | ||
{ | ||
this.unsubscribeNodeEvents(nodeViewModel); | ||
nodeViewModel.Dispose(); | ||
foreach (var nodeViewModel in Nodes) | ||
{ | ||
this.unsubscribeNodeEvents(nodeViewModel); | ||
nodeViewModel.Dispose(); | ||
} | ||
Nodes.Clear(); | ||
} | ||
Nodes.Clear(); | ||
Errors.Clear(); | ||
|
||
PostNodeChangeActions(); | ||
|
@@ -685,9 +688,13 @@ private void unsubscribeNodeEvents(NodeViewModel nodeViewModel) | |
|
||
void Model_NodeRemoved(NodeModel node) | ||
{ | ||
NodeViewModel nodeViewModel = Nodes.First(x => x.NodeLogic == node); | ||
Errors.Remove(nodeViewModel.ErrorBubble); | ||
Nodes.Remove(nodeViewModel); | ||
NodeViewModel nodeViewModel; | ||
lock (Nodes) | ||
{ | ||
nodeViewModel = Nodes.First(x => x.NodeLogic == node); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess this is safest, but is there any harm in scanning the collection outside the lock? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The thing is you can run into errors by enumerating over it while it's being modified. That's the initial crash I found. |
||
Errors.Remove(nodeViewModel.ErrorBubble); | ||
Nodes.Remove(nodeViewModel); | ||
} | ||
//unsub the events we attached below in NodeAdded. | ||
this.unsubscribeNodeEvents(nodeViewModel); | ||
nodeViewModel.Dispose(); | ||
|
@@ -700,7 +707,10 @@ void Model_NodeAdded(NodeModel node) | |
var nodeViewModel = new NodeViewModel(this, node); | ||
nodeViewModel.SnapInputEvent += nodeViewModel_SnapInputEvent; | ||
nodeViewModel.NodeLogic.Modified += OnNodeModified; | ||
Nodes.Add(nodeViewModel); | ||
lock (Nodes) | ||
{ | ||
Nodes.Add(nodeViewModel); | ||
} | ||
Errors.Add(nodeViewModel.ErrorBubble); | ||
nodeViewModel.UpdateBubbleContent(); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change may have significant performance impacts - we should investigate the original reason for the implementation - my memory is that when moving a slider it kicked off hundreds of unnecessary runs and made dynamo unresponsive - if this is related then theres an argument that the crash is actually acceptable...?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Strange that was fixed by doing this instead of throttling the requests created by the slider 🤔
Still, maybe we could restore a more elaborate merge strategy that accounted for this case in particular. What kind of
graphSyncData
would we expect? Do we have a test case?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
heres part of the discussion I recall:
#4276
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and a related github issue:
#4229
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delay
seems to work just fine according to my manual testing. Is there any special validation you would like to make beyond what's shown in that issue?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned if there are other scenarios (other than the slider) where we are not dropping redundant tasks that are quickly accumulating as a result of this change thus hitting performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't control the UI that other package authors may build - delay for the slider is great, but it does not cover the case generally, though I guess we could document the idea somewhere to throttle their controls?
For example I am thinking of controls like:
and
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Granted. For those cases having a strategy to merge/discard would be useful. I'll try to come up with something.