It was never actually used apart from being stored at a construciton time.
This caused some redundancy and ncertanty about which relation type to use
during construciton (often existing types were not close enough to particular
use case).
The idea is to accumulate all new tasks in a thread local queue
first without doing any thread synchronization (aka, locks and
conditional variables) and move those tasks to a scheduler queue
once they are all ready. This way we avoid per-task-pool lock
and only have one lock per bunch of tasks.
This is particularly handy when scheduling new dependency graph
node children. Brings FPS of cached simulation from the linked
below file from ~30 to ~50.
See documentation for BLI_task_pool_delayed_push_{begin, end}
and for TaskThreadLocalStorage::do_delayed_push.
Fixes T50027: Rigidbody playback and simulation performance regression with new depsgraph
Thanks Bastien for the review!
This way we always have predictable behavior, especially from the
performance point of view. Additionally, if some bottleneck is found
in stack implementation it'll be easier for us to address.
Was preventing update in 3DView etc. when changing something in the
World's NodeTree, especially annoying in blender2.8 branch (since legacy
depsgraph has been removed there), but also affecting master.
A bit too early to disable workaround for particles.
Guess it was commented out after particles removal but was not brought back
after particles restore commit.
The change was initially needed for Blender 2.8 branch but the actual
function was reverted in there. So no reason to keep dead unused
placeholder in the dependency graph.
This reverts commit fd69ba2255.
Selection code needs to iterate over DEG_OBJECT_ITER otherwise we won't
get modifiers, dupli objects, ...
Also make selection respect selectability flag.
Review by: Sergey Sharybin
Pending: Include the set in the rna depsgraph.objects
In fact it would be nice to unify them both. However this will likely
change once Depsgraph incorporate this iterator, so I'm not sure we
should bother with that.
Related to T51203
Even though this will have to change once we get workspaces, we will
still have a depsgraph for the Scene.
This is required for the upcoming depsgraph.objects RNA iterator.
These bits became obsolete with the new layer system, so we can
simplify some code around them or avoid existing workarounds which
were trying to keep things working for them.
There are still work needed to be done for on_visible_change to
avoid unnecessary updates, but that can also happen later.
This moves selectability/visibility flag flush from some hardcoded
places in the code to depsgraph. This way it is possible to simply
tag depsgraph to update those flags and rest it'll do on its own.
Using depsgraph for such flush is an overkill: those flags are fully
static and can not be animated, so it doesn't really make sense to
hook only those to depsgraph.
However, in the future we will have overrides on collections, which
ideally would need to be animatable and drivable and easiest way
to support this is to do this on depsgraph level, so it ensures
proper order of evaluation for animation and drivers. And it seems
logical to do both overrides and flags flush from depsgraph from
this point of view.
This commit also includes the evaluation of IDProperty for collections,
which basically are just another form of override. So once we implement
the other kind of overrides the flushing and collection evaluation won't
change.
Patch by Sergey Sharybin and Dalai Felinto
