There were following issues:
- This was used in a similar way of DEG's ID update callback. No reason to have
yet-another-way of informing editors/engines about changes. Better to keep
regular update mechanism usable and fast for those needs.
- It wasn't granular at all, and granularity in flags is something what we
need to support anyway, even for existing ID update.
- There is no reason to have it per-object. Depsgraph operates on IDs.
- It wasn't clear when and who clears the flag, and was possible to run into
conflicts.
This commit effectively reverts fix T45702 done in 067fe2719a.
Reasoning:
- Blender Internal is being replaced with Eevee, and will be removed entirely
rather soon.
- All render engines are planned to have own depsgraph, so such threading
conflicts should no longer be an issue.
- We don't want to spend time on porting workarounds for EOL things to a new
design. Less code -- faster the work :)
- If such notifications will end up needed for some other cases, we would
need to re-implement this a more proper depsgraph tagging/flushing and make
it to work with all copy-on-write datablocks and everything.
There might be much more logic involved there, also we might not know proper
evaluated CoW pointer there yet. So we leave this to dependency graph to
decide what exactly to do here.
This reverts commit 90ff88646d.
Can not do this yet, if object is not part of graph yet it will not have entry
taq. Need some more generic solution here.
It is possible to have situation when we need to both update relations and do
some updates on random IDs. This was only done before for objects using their
recalc field. This means, every update tag which did not fit into there would
have been lost after updating relations.
Now we do some smarter re-scheduling of operations after relations are updated.
Previously it was done during depsgraph iteration, which is not good at all,
since after evaluation nobody should really modify how object was evaluated.
The idea then is to avoid doing depsgraph tag for each of the object which
selection is changed (which could be tricky to do anyway due to lots of areas
of selection code where this could happen), and simply tag scene's with
selection update tag.
This will involve synchronization of flags from base to objects, which is
rather cheap anyway.
This is crucial bit since batch cache is stored in the evaluated object,
meaning we can't tag it's hatch cache dirty from the notifier system.
Not easily at least. Better to leave this job to depsgraph, it knows
all the copies of data.
