This mainly removes the bmain argument, which can be
retrieved from the graph itself.
Also, I removed some outdated/unnecessary comments.
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8614
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
While investigating T76274, I found crash scenario when playhead is near end
frame and moving a strip. It is not as easy to reproduce, about 5% success
rate, and it will be even harder after rB4066c921fbe5. Exact cause wasn't
identified yet.
I wanted to disable prefetching during modal operator execution in VSE, but
currently I don't have any signalling method in place. Checking for G.moving
seems to resolve this problem, but it doesn't adress root cause of bug.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7820
This bug is not really visible for user. When end frame is reached by
prefetching thread, it doesn't stop and keeps on getting images from
cache.
Add chech for this situation and simplify logic involved in suspending,
so it's easier to read.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7757
Prefetching is stopped in BKE_sequencer_cache_cleanup, but is restarted quickly.
Prefetching has negative effect on performance while rendering.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7751
Disable (skip) preftching scene strips if they target 3D scene.
Try to continue prefetching complete frame if disk cache images are found.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7514
`BKE_sequencer_prefetch_get_original_sequence()` didn't look in metas
and returned NULL. This caused crash in disk cache that was trying to
read seq->name.
Add function that will look in meta strips recursively and condition
that seq must not be NULL.
Reviewed By: brecht
Maniphest Tasks: T76033
Differential Revision: https://developer.blender.org/D7597
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
When enabled prefetching(preview panel>view settings), a pernament running job
is created, that will render frames in the background until the cache is full.
If the cache is not filled fast enough, prefetch job suspends itself
at the last moment and will wait until it has chance to "catch up".
Effectively this will decouple rendering to separate thread, so rendering
itself is a bit faster.
Cache recycling behavior will be changed to "free furthest frame to the left
of playhead if possible, otherwise rightmost frame".
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5386