Today did some performance tests concerning the performance degradation when keyframing scene strips.
We found low hanging fruit as the scene strips didn’t had a lookupstring callback and would iterate over strips. This is being taken care of.
The second topic we want to address is to ignore fcurves from strips that aren’t active in current frame.
Logically at the start of the animation system we could:
for strip in scene.sequencer_strips:
ignore_fcurves = strip.is_active_on_current_frame(scene)
for fcurve in scene.fcurves_targetting(strip):
fcurve.ignore_during_evaluation = ignore_fcurves
By ignoring the fcurves we can reduce rna path lookups and reduce unneeded looping in the animation system. The lookup from a target to a fcurve is much cheaper and can be done with a string comparison. fcurve.path.startswith(f"sequences_all["{strip.name}"). The idea behind this is that most fcurves related to sequencer strips don’t influence the current frame.
This is a bit tricky as you can still animate settings of strips even when they don’t act to the current frame. To mitigate this we could:
- don’t ignore fcurves if the target property has a driver.
- only do this during animation playback.
Before researching any further I want to discuss if this could be a valid solution and if this should have impact on the depsgraph or would only effect the animation system.
3 Likes
Great to see you guys looking into the very poor performance of Scene strips.
I don’t know what systems will be affected by limiting the f-curve lookups, however keep in mind that some f-curve lookup is needed for the f-curve drawing on strips:
1 Like
Hi @tintwotin this isn’t about scene strips, but fcurves that influence strips for example transparency, volume etc. It should not effect the drawing as that is done during drawing. But good to keep an eye on that.
Ok. One more f-curve drawing patch(for speed strips) waiting for a review: https://developer.blender.org/D6110
Btw. must be magic with the 20fps > 300fps speed enhancement of transform operations! Maybe the VSE scaling could need a similar checkup?
Will fcurve.ignore_during_evaluation be a newly introduced flag for all fcurves? If not, then you can ignore the rest of this post. Assuming it is, consider that sequencer pre-animation evaluation code is required anyways and fcurve muting achieves the same result. So maybe a new flag isn’t necessary? We would just use the existing mute flag and cache the prior mute value before the animation system evaluates then restore it afterwards.
@GuiltyGhost for code clarity I would separate internal flags from user oriented flags. So this would be a separate flag that isn’t direct controllable by users. Behavior might look the same as muting when looking at it from a birds eye viewpoint, but you don’t want that the user oriented change is done by internals. That could lead to bugs…
⚙ D11544 VSE: Improve animation evaluation performance points out that we don’t need to implement ignoring fcurves during evaluation. The low hanging fruit (lookupstring callback) works better than expected.