(The automated testing for this is a bit more complicated - at this stage what I want to understand is: is there any reason that we can't follow this strategy?)

This was what I tested, and it seemed to work well. I think merging update graph tasks can only be a good thing. The only time the scheduler gets flooded with update requests is when someone is sliding a slider. And the desired behavior during slider sliding is that graph updates feel as immediate as possible. So this makes that possible. And, because rendering is tied to update (we render some amount of stuff every time we update), and because rendering is more expensive than update in many cases, it is to everyone's benefit to render less - that is, to update less.

Hi @ikeough, @lukechurch, an UpdateGraphAsyncTask keeps the GraphSyncData for a bunch of nodes that are currently marked as modified at the time UpdateGraphAsyncTask.Initialize method is called. Consider a case where NodeA is updated before NodeB, and both these node changes result in two instances of UpdateGraphAsyncTask objects in the pipeline, the modification on NodeA will be discarded.

If we really do want to decide if either of the tasks should be kept, then we need to implement a strategy that meaningfully compares the tasks. For a start, I think storing IEnumerable<System.Guid> in each of the UpdateGraphAsyncTask for the nodes that it is meant to update, then use it for comparison (e.g. SequenceEqual) should be good enough. Let's not store the NodeModel themselves, I'd rather not have UpdateGraphAsyncTask hold more references to NodeModel objects if possible (and System.Guid comparison is quick, too).

Does that make sense?

@benglin I see.

We could certainly use a comparison based strategy to fix the most common case which is a slider manipulation.

In general it seems that what we need is an API where we can take two tasks and instead of simply comparing them, we can return a new task that replaces both. In this case it would be computing the union of the modified nodes?

Oops, sorry @lukechurch I had this open in a browser tab and didn't get back to it before a system restart. To fix the slider case, adding a list of System.Guid would help for now (as outlined in my comment above). Task merging by taking a union requires a scheduler to be tweaked and I personally do not think that justifies the problem it solves. If you would still prefer to have task merging, then perhaps we can have a chat about it and get that implemented, too. Thanks again for fixing this!

@benglin np, thanks for the input PTAL at these changes which I think address the concern