MAYA-128407 fix edit-target loops in proxy shape compute

[pierrebai-adsk]

The problem is recursive interactions between multiple actors.

First actor: the ProxyAccessor class.

This class is only vaguely documented, that is there is a mechanical description but not an explanation of why it needs to exists nor why it is written as it is. It's mechanical purpose, as I understand it from its docs, is to copy input plugs into the proxy shape to stage data and copy stage data to output plugs. For some reason which are not explained, it writes its data to the session layer. To do so, it temporarily sets the target layer to the session layer.

Second actor: the ProxyShapeBase class.

The class is the representation of the USD stage as a Maya node. As part if its computation, it creates the stage. It holds multiple attributes to do so:

• The root layer
• The session layer
• The list of muted layers
• The load/unload state of various payload
• The current edit target layer.

And, in its implementation of its computation uses the ProxyAccessor. So, computing the ProxyShapeBase use a ProxyAccessor, which switch the target layer.

Third actor: the Edit Target Notifications

In order for the ProxyShapeBase to set the correct edit target when computed, it needs to know when the edit target has changed. Otherwise, after the user changed the edit target, recomputing the ProxyShapeBase would set the edit target to the old target. So the ProxyShapeBase register a notification listener to be told when the edit target changes. When the edit target changes, the notification listener sets the edit-target attribute on the ProxyShapeBase so that it sets the correct target if it is recomputed.

End Result

So, the sequence of events is:

• The ProxyShapeBase is recomputed.
• The ProxyAccessor changes the target to the session layer.
• This trigger the edit-target change notification
• This updates the ProxyShapeBase attribute
• This dirties the ProxyShapeBase
• The ProxyShapeBase compute ends.
• This destroys the ProxyAccessor
• This reset the edit target to its previous value.
• This trigger the edit-target change notification
• This updates the ProxyShapeBase attribute
• This dirties the ProxyShapeBase
• And... now the ProxyShapeBase will get recomputed again when accessed.

There are two ways to break the chain:

• Detect temporary changes in the edit target and ignore them.
• Not dirty the ProxyShapeBase when the edit target change.

The first one would be dangerous since if a recompute is triggered at that moment, it would use the incorrect edit target. OTOH, it is unclear what is the correct edit target at that point: is it the temporary edit target set by the proxy accessor or the edit target set by the user?

The second one can be done by keeping the current edit target in a member variable in the ProxyShapeBase and only use the attribute at load time to initially fill that variable, say on the first compute. I think that is what I will do to fix the problem.

• Add a member variable to ProxyShapeBase to keep track of the current edit target.
• Fill it on first compute.
• Update it when the edit target change, via the notifications.
• Only save the edit target on save (this was already existing).
• Refactor edit-target helper functions to support all this.

[vlasovi]

Looks good. Thanks for removing the "on idle" callback.