Page MenuHome

Approach Faster Animation Playback
Confirmed, NormalPublicDESIGN


The Faster Animation Playback second milestone consist out of non-functional requirements. This document will describe the steps we want to follow to execute that milestone.


The goal of the second milestone of T68908: Faster Animation Playback is to increase the playback performance when using Blender as an animator by optimizing the current weaknesses. As viewport rendering and viewport playback are very tight related most changes will impact both of them and all changes should be tested to both use cases.


Phase 0: Preparation

  • Select several production scenes that will be used as benchmark (@Hjalti Hjálmarsson (hjalti))
    • Scenes from different productions with different rigs and different sizes.
  • Modify blender to profile what is happening during animation playback. (@Jeroen Bakker (jbakker)
    • Depedency Graph: Depedency Graph has a detailed profiler. Just need to check if it is sufficient.
    • Draw Manager: Draw manager already has a detailed profiler. We might want to add small changes (for example separate mesh_extraction from preparation)
    • Other: We should keep track of the rest of the time (not inside the Dependency graph/Draw manager) to detect balance shifts in performance
  • Create an automated test that records the timings in a database so we could compare the results and make decisions (@Jeroen Bakker (jbakker))
  • Document the hardware/OS's for the benchmark that will be used
  • Perform a base benchmark

Phase 1..n: Performance Cycle

When doing performance test you do a single change at a time and monitor what that change does to the whole system. To make a change we suggest the next approach

  • Find the current weakest area
  • Do one or more prototypes to solve the weakest link
  • Select the solution.
  • Create design (mention the other solutions as alternatives) and implement the solution.
  • User test the chosen solution. (@Hjalti Hjálmarsson (hjalti))
  • Codereview and merge to master.

Only after we complete a full cycle we can start with the next cycle. We continue this until we reached a workable performance or the year has ended.


This approach tends to be too narrow focused when looking for solutions. When looking for solutions we should keep in mind to look at the whole picture and not limit the solution to the area in focus.

Known areas of improvement

This section contains a collection of known issues that we might want to tackle during the project

  • DrawManager mesh extraction uses a task pool per mesh. When two meshes needs to be updated for a frame it happens in serial.
  • Blender's task pool has been setup originally for long running background processes. It is currently used for tasks of all sizes.
  • Better select the frame ranges that needs to be updated for motion curves.
  • VSE/Graph editor dependencies. (ref play in active area)

Related Objects

ConfirmedTO DONone

Event Timeline

Jeroen Bakker (jbakker) changed the task status from Needs Triage to Confirmed.Mon, Jan 27, 11:13 AM
Jeroen Bakker (jbakker) created this task.
Jeroen Bakker (jbakker) changed the subtype of this task from "Report" to "Design".
Jeroen Bakker (jbakker) renamed this task from EngineeringPlan: Faster Animation Playback Global Approach to [WIP] Global Approach Faster Animation Playback.Mon, Jan 27, 11:53 AM
Jeroen Bakker (jbakker) updated the task description. (Show Details)
Jeroen Bakker (jbakker) renamed this task from [WIP] Global Approach Faster Animation Playback to Approach Faster Animation Playback.Mon, Jan 27, 1:17 PM

Here I've often found this rather unexpected culprit that can make playback slow:

Having the Dopesheet vand/or Graph Editor visible can sometime more than halve (!) the playback speed, simply because Blender spends so many resources re-drawing the keyframes and curves, always every frame. This seems silly. Surely it doesn't need to do that, or it could perhaps be optimized?

@William Reynish (billreynish) that is what is referred to with the VSE/Graph editor dependencies. most of the time the whole screen is updated, but the user is just looking at a single area. There seems to be an option that is used by the animators here where only the area is updated where the mouse is Active Editor Only.

I would like to add that disabling "Auto smooth" from meshes will increase performance while previewing animation in viewport.

Here's an example: