Change Details

The Faster Animation Playback consist most out of non-functional requirements. It doesn't fit in the expected UI/UX related project approach so this document will be setup more related to the steps that we take. ==Goal== The goal of the {T68908} is to increase the playback performance when using Blender as an animator. This is the viewport playback, viewport rendering. 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. == Approach == ===Phase 0: Preparation=== * Select several production scenes that will be used as benchmark (@hjalti) * Modify blender to profile what is happening during animation playback. (@jbakker ** Depedency Graph: Record global and per modifier the thread-cpu-time it used. ** 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 (@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) * 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. == 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.

The Faster Animation Playback consist most out of non-functional requirements. It doesn't fit in the expected UI/UX related project approach so this document will be setup more related to the steps that we take. ==Goal== The goal of the {T68908} is to increase the playback performance when using Blender as an animator. This is the viewport playback, viewport rendering. 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. == Approach == ===Phase 0: Preparation=== * Select several production scenes that will be used as benchmark (@hjalti) * Modify blender to profile what is happening during animation playback. (@jbakker ** Depedency Graph: Record global and per modifier the thread-cpu-time it used. ** 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 (@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) * 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. == 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) * Animation caching with area of influence and background jobs. Perhaps as a separate project?

The Faster Animation Playback consist most out of non-functional requirements. It doesn't fit in the expected UI/UX related project approach so this document will be setup more related to the steps that we take. ==Goal== The goal of the {T68908} is to increase the playback performance when using Blender as an animator. This is the viewport playback, viewport rendering. 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. == Approach == ===Phase 0: Preparation=== * Select several production scenes that will be used as benchmark (@hjalti) * Modify blender to profile what is happening during animation playback. (@jbakker ** Depedency Graph: Record global and per modifier the thread-cpu-time it used. ** 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 (@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) * 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. == 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) * Animation caching with area of influence and background jobs. Perhaps as a separate project?