5.0, 5.1 are 50% less performant for playback with 2 rigify armatures, 20fps in 4.4, 10fps in 5.0 #57
Assignees
Triager-bot
Clear assignees
Triager-bot
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Triager-bot/blender-bug-reports#57
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Original bug report: https://projects.blender.org/blender/blender/issues/157238
System Information
Operating system: Windows-10-10.0.26200-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3090 NVIDIA Corporation NVIDIA 591.86 Vulkan Backend
Blender Version
Broken: version: 5.0.1, branch: blender-v5.0-release, commit date: 2025-12-15 16:36, hash:
a3db93c5b259Worked: (newest version of Blender that worked as expected)
Short description of error
When comparing playback of two rigify armature, blender 5 gets 10fps, blender 4 20fps.
Exact steps for others to reproduce the error
Download project, one anim file that has character file linked (relative path), and a 4.4/4.5 version of this anim file (called debug)
hit spacebar to playback, you should get 10 fps for the blender 5 version, 20 fps for the blender 4.
https://www.dropbox.com/t/ZJvRHl8cxQrnu9eY
Another issue is that global undo adds up to 10 seconds of freeze after every single click, in this relatively simple project. Fhis comes from the fact there are 24 needed duplicates of the rigify character, and for each, global undo adds half a second of freeze after any click inside blender.
It's the first time I need a couple dozen characters in a project, and I had no idea this wasn't supported by global undo. The current workaround is to disable it, remove the Ctrl+Z hotkey (otherwise you wipe all your work since opening the file when hitting Ctrl+Z) and just put autosaves on dropbox so you get a snapshot of your file every minutes.
I made lots of projects with up to a dozen rigify characters, but never had any of these two issues before 5.0: playback being impossibly slow, global undo preventing any productive interaction with blender.
Many thanks if you can check on your end.
Report is clear
LLM Reasoning
Got it, let's see. The question is whether the bug report clearly describes the issue. First, I need to check the clarity of the text and steps to reproduce.
The title mentions performance difference between 4.4 and 5.0 with rigify armatures. The body has a short description: playback fps difference (10 vs 20). Then exact steps: download project, hit spacebar, get different fps. Also mentions another issue about global undo freeze, but the main one is the playback performance.
Wait, the user is asking if it clearly describes the issue. Let's check:
Is the text clear? Yes, because it states what's wrong (performance drop in 5.x vs 4.x with rigify armatures), how to reproduce (steps), and the expected result. So the answer should be 'Yes'.
JSON Data
{
"llm_judgement": true,
"processing_time": 14.960977000000002
}
Report is specific
LLM Reasoning
Got it, let's analyze the bug report. The title mentions specific versions (5.0, 5.1) and a comparison between Blender 4.4 and 5.0 for playback performance with two rigify armatures. The body gives exact steps to reproduce, including downloading a project and comparing fps. Also, there's another issue about global undo freeze, but the main point is specific versions and a concrete scenario (two rigify armatures). So this is a specific bug report because it's about a particular issue with specific versions and reproducible steps. Wait, but let me check the definition: Specific is about a specific issue like crashing while using a specific feature. Here, the issue is playback performance difference between 4.4 and 5.0 with two rigify armatures, which is specific. So the answer should be 'Specific'.
JSON Data
{
"llm_judgement": true,
"processing_time": 12.655205
}
Report flagged as NOT a duplicate by LLM
Performance degradation caused by global undo
https://projects.blender.org/blender/blender/issues/157141
System Information
Operating system: Windows-11-10.0.26200-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 Laptop GPU NVIDIA Corporation NVIDIA 591.74 Vulkan Backend
Blender Version
Broken: version: 5.1.1 Release Candidate, branch: blender-v5.1-release, commit date: 2026-04-08 12:38, hash:
6e7aed26d98cWorked: (newest version of Blender that worked as expected)
Short description of error
Version 5.1rc has a performance drop caused by undo; when global undo is checked, any operation becomes slower. Currently, it is unclear how to reproduce this. Based on my experience using 5.1, a long-term animation project with a character rig seems to accumulate this performance-degrading delay. Even my own project, which was very smooth and responsive in version 4.5, experiences performance issues in the current 5.1 and 5.1.1 rc versions.
Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps.
Bug report 1 mentions two issues: playback performance with rigify armatures (5.0 is slower than 4.4) and global undo causing freezes after each click, especially with many duplicates of rigify characters. The steps involve downloading a project with anim files and playing back to see fps difference, plus the undo issue.
Bug report 2's title is "Performance degradation caused by global undo" and describes that when global undo is checked, operations are slower, especially in long-term projects with character rigs. But the steps section is empty (needs reproduction steps).
Now, check if they're the same. Bug report 1 has both playback performance and global undo issues. Bug report 2 focuses on global undo causing performance degradation. The first report's global undo issue is about freezes after each click due to many duplicates, while the second is a general performance drop with global undo enabled. Are these the same? Let's see: the first report's global undo problem is specific (many rigify characters leading to freeze), the second is more general (any operation slower with global undo). But wait, the question is if they're the same issue. The first has two issues: playback and global undo. The second is only about global undo performance. So are the global undo parts the same? Let's check the descriptions. Bug 1 says "global undo adds up to 10 seconds of freeze after every single click" due to many rigify duplicates. Bug 2 says "when global undo is checked, any operation becomes slower" in projects with character rigs. Maybe related, but are they the same issue? The first report's playback issue is separate (5.0 vs 4.4 fps), which bug 2 doesn't mention. So the two reports have overlapping parts (global undo performance) but also different issues (playback in bug 1). Since the question is if they're the same, and bug 1 has an additional playback issue not present in bug 2, they aren't duplicates. So answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 26.009427,
"duplicate_report_number": "157141"
}
Report flagged as NOT a duplicate by LLM
Performance Regression: Global Undo causes ~0.5s+ lag per action in all 5.0 versions
https://projects.blender.org/blender/blender/issues/153100
System Information
Operating system: Windows-10-10.0.26100-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 5090 NVIDIA Corporation NVIDIA 591.44 Vulkan Backend
Blender Version
Broken: version: 5.1.0 Alpha, branch: main, commit date: 2026-01-20 00:11, hash:
4025fe85d300Worked: (newest version of Blender that worked as expected)
Short description of error
Significant lag (approx. 0.5s) occurs after every action that triggers a Global Undo save state in medium to heavy scenes. This behavior is consistent across all versions of Blender 5.0 and 5.1 Alpha.
The issue is completely mitigated by disabling Global Undo in preferences.
Key Observation: The lag is most easily observable when moving the timeline frame-by-frame. The system appears to attempt a state save for every frame increment, causing the 0.5s delay to compound into a severe stutter or freeze during rapid frame changes.
Exact steps for others to reproduce the error
Open Blender (any 5.0+ build).
Load a scene with medium complexity (lag is less apparent in the default startup scene).
Ensure Global Undo is enabled.
Method A (Modeling): Perform a transform action (G/R/S) and observe the ~0.5s freeze after confirming.
Method B (Timeline - Most Obvious): rapid-fire the arrow keys to move the timeline frame-by-frame. Observe that the interface becomes unresponsive or extremely laggy as the undo save state triggers for each frame.
Disable Global Undo (Edit > Preferences > System > Memory).
Repeat the timeline test; observe that frame changes become instant and fluid.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.
Bug report 1 talks about playback performance with rigify armatures (20fps in 4.4 vs 10fps in 5.0) and global undo causing freezes after every click (especially with many duplicates). The steps involve downloading a project, playing back animation, and noting the fps difference, plus the undo issue.
Bug report 2 is about global undo causing ~0.5s lag per action in 5.0+ versions, especially when moving timeline frame-by-frame or doing transforms. Steps are to enable global undo, perform actions (like timeline arrows or transforms) and observe lag, which goes away when disabling global undo.
Now, check if they're the same issue. Bug report 1 mentions global undo adding up to 10 seconds of freeze after every click in a project with many rigify characters. Bug report 2 is specifically about global undo causing ~0.5s lag per action (like timeline frame changes or transforms). The key here is that both mention global undo performance issues, but bug report 1 also has playback performance with armatures, while bug report 2 focuses on the global undo lag in general actions.
Wait, but are they duplicates? Let's see: Bug report 1's global undo issue is about many duplicates causing freeze after every click. Bug report 2's is about any action triggering global undo (like timeline or transforms) causing ~0.5s lag. The core of both is global undo performance regression in Blender 5.0+. But bug report 1 also has the playback performance with armatures, which is a separate issue? Wait no, wait: Bug report 1's main issues are two: playback slowdown (rigify armatures) and global undo freeze. Bug report 2's only issue is global undo lag. So are they the same?
Wait, let's check the descriptions again. Bug report 1 says "global undo adds up to 10 seconds of freeze after every single click" in a project with many rigify characters. Bug report 2 says "Significant lag (approx. 0.5s) occurs after every action that triggers Global Undo save state". So both are about global undo causing performance issues. But bug report 1 also has the playback issue, which is separate. However, the question is if they are the same issue. Let's see: Are the two reports describing the exact same problem?
Bug report 1's global undo issue: freeze after every click in a project with many rigify characters. Bug report 2's global undo issue: lag per action (timeline frame changes, transforms) in any medium/heavy scene. The core is global undo performance regression. But are they duplicates? Let's think: If the root cause is the same (global undo being slow in 5.0+), then maybe. But bug report 1 has an additional playback issue with rigify armatures. Wait, but the question says to focus on 'Description of issue' and 'Steps to reproduce'.
Bug report 1's description: playback performance (rigify armatures) and global undo freeze. Steps: download project, play animation (fps difference), and note undo freeze.
Bug report 2's description: global undo lag per action. Steps: enable global undo, perform actions (timeline arrows, transforms) to see lag.
Are these the same issue? The global undo part in bug report 1 is about many duplicates causing freeze after every click, while bug report 2 is about any action (like timeline or transform) causing ~0.5s lag. So maybe they are related but not the same? Wait, no—maybe the global undo issue is the same root cause, but reported in different contexts. But the question is if they are duplicates. Let's check: Do both reports describe the exact same problem?
Bug report 1 has two issues: playback slowdown (rigify) and global undo freeze. Bug report 2 has only global undo lag. So if we consider that the global undo part is a separate issue from the playback, then maybe not. But wait, the user says to focus on 'Description of issue' and 'Steps to reproduce'. Let's check:
Bug report 1's description includes both playback and global undo. Bug report 2's description is only global undo. So are they the same? No, because bug report 1 has an additional playback issue. Wait, but maybe the playback issue is a separate problem, and the global undo is another. But the question is if the two reports are the same issue. Let's see: If we ignore the playback part of bug report 1, then the global undo parts might be similar. But since bug report 1 has an additional issue (playback), they aren't duplicates. Wait, but maybe the user considers that the global undo is the main issue in both? No, because bug report 1's title is about playback performance, and the body includes both. Bug report 2's title is about global undo lag.
Wait, let's re-express:
Bug report 1: Two issues—playback (rigify armatures) slow down from 4.4 to 5.0, and global undo freeze after every click in a project with many rigify characters.
Bug report 2: Global undo causes ~0.5s lag per action in 5.0+ versions, regardless of scene complexity (medium/heavy).
So the global undo parts are similar but reported in different contexts (bug report 1 has many duplicates, bug report 2 has any medium scene). But are they the same issue? The steps to reproduce: Bug report 1's steps involve a specific project with rigify characters and playback. Bug report 2's steps involve any medium/heavy scene and timeline/transforms.
So, are they duplicates? No, because bug report 1 includes a playback performance issue that bug report 2 doesn't mention, and the global undo issues are reported in different contexts (specific project vs general). Therefore, they are not the same issue. So the answer is 'No'.
JSON Data
{
"llm_judgement": false,
"processing_time": 68.355194,
"duplicate_report_number": "153100"
}
Report flagged as NOT a duplicate by LLM
FPS Drops to 1/3 during playback when keyframing bones. Fault is of slots in action editor.
https://projects.blender.org/blender/blender/issues/146948
System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 NVIDIA Corporation NVIDIA 581.29 Vulkan Backend
Blender Version
Broken: version: 4.5.3 LTS, branch: blender-v4.5-release, commit date: 2025-09-08 12:46, hash:
67807e1800ccWorked: Not sure.
Short description of error
FPS during playback drops by 1/3 when there is an action and keying the bones.
My FPS went from 240 to 80~ish when i added keyframes on an empty rigify rig in an empty blend file. Removing the action from the action editor bumps the FPS back to 240.
Same thing happens on a production character file and that was the reason I tested with a empty rigify rig.
Exact steps for others to reproduce the error
A blank Rigify rig example file is attached.
A vide is also attached.
Let me know if I need to provide anything else.
Thanks!
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the key parts: description and steps.
Bug report 1 talks about playback performance with rigify armatures—5.0 is slower (10fps vs 4.4's 20fps) when playing back an anim file with linked characters. Also mentions global undo issues, but that's a separate point maybe.
Bug report 2 is about FPS dropping by 1/3 during playback when keyframing bones in the action editor. Steps involve adding rigify rig, keying bones, checking FPS drop, then removing action to fix. The issue here is related to keyframing and action slots affecting playback FPS.
Now, are these the same? Let's check the core issues. Report 1 is about playback performance difference between versions (5.0 vs 4.4) with rigify armatures in a specific project. Report 2 is about FPS drop when keyframing bones (action editor) regardless of version (mentions 4.5.3 LTS). The causes seem different: one is version-specific playback speed, the other is action editor slot issue causing FPS drop during keyframing. So they're not the same issue.
JSON Data
{
"llm_judgement": false,
"processing_time": 17.603617999999997,
"duplicate_report_number": "146948"
}
Report flagged as NOT a duplicate by LLM
5.1 Animation performance regression
https://projects.blender.org/blender/blender/issues/155555
System Information
Operating system: Ubuntu 22.04
Graphics card: NVIDIA 4070
Blender Version
Broken: 5.1
Worked: 5.0
Broken by: 31dd352e841828ef39347a4a5455569d9ec40f5e
Short description of error
While testing the file in #155551, I get a performance regression with 5.1 compared to 5.0.1.
In 5.1 it's about 12 fps on my machine where on 5.0.1 it's around 20.
Exact steps for others to reproduce the error
Play animation in the file from #155551 with both 5.1 and 5.0.1.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the description and steps.
Bug report 1 talks about playback performance: 4.4 has 20fps, 5.0 has 10fps with two rigify armatures. Also mentions global undo issues, but the main performance part is playback speed difference between versions.
Bug report 2 is about animation performance regression in 5.1 vs 5.0.1: 12fps in 5.1 vs 20fps in 5.0.1, using a specific file from another bug (#155551).
Now, check if the core issue is the same. Both are about performance regression (slower playback) between Blender versions (4.x to 5.0/5.1). But wait, report 1 compares 4.4 vs 5.0, report 2 compares 5.0.1 vs 5.1. Also, report 1 mentions rigify armatures and a specific project with duplicates, while report 2 refers to a file from another bug. Are they the same issue? Let's see: both are performance regressions in animation playback across Blender versions. But maybe different contexts (rigify vs general animation). However, the key is if the description and steps point to the same problem.
Wait, the question is whether they are duplicates. Let's check:
Report 1: Playback with 2 rigify armatures, 20fps in 4.4, 10fps in 5.0.
Report 2: Animation performance regression, 12fps in 5.1 vs 20fps in 5.0.1, using a file from #155551.
Are these the same issue? The core is performance drop in newer versions during animation playback. But report 1 has specific rigify armatures and a project with duplicates, report 2 is about a general animation file. However, maybe they are related but not exact duplicates. Wait, the user says to focus on Description and Steps.
Report 1's steps: download project with rigify armatures, play back, check fps difference between 4.x and 5.0.
Report 2's steps: play animation in a file from another bug, compare 5.1 vs 5.0.1 fps.
Are these the same issue? The main theme is performance regression in animation playback across Blender versions. But are they duplicates? Let's see if the problem is identical. Report 1 mentions rigify armatures and global undo (but that's a separate issue), report 2 is about general animation. Maybe not exact duplicates, but let's check.
Wait, the question is "are they the same issue?" So we need to decide Yes or No.
Looking at the descriptions: both are about performance regression in playback between versions. But report 1 has specific rigify armatures and a project with many duplicates, report 2 is about a different file (from #155551). Are these the same underlying problem? Maybe, but maybe not. However, the user says to focus on Description and Steps.
Report 1's description: "When comparing playback of two rigify armature, blender 5 gets 10fps, blender 4 20fps."
Report 2's description: "While testing the file in #155551, I get a performance regression with 5.1 compared to 5.0.1. In 5.1 it's about 12 fps on my machine where on 5.0.1 it's around 20."
So both are about lower fps in newer Blender versions during animation playback. But the context (rigify vs general) might differ. However, maybe they are duplicates because the core issue is performance regression in animation playback across versions. But wait, report 1 compares 4.x to 5.0, report 2 compares 5.0.1 to 5.1. Are these part of the same regression chain?
Alternatively, maybe not. Let's think: if two reports are about the same problem (performance drop in animation playback) even with different contexts, are they duplicates? The user says "your focus should primarily be on the 'Description of issue' and 'Steps to reproduce the issue' section."
Report 1 steps: download project with rigify armatures, play back.
Report 2 steps: play animation in a file from another bug.
Are these steps similar? Not exactly. Report 1 has a specific project (with rigify), report 2 refers to another bug's file. So maybe not the same issue. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 51.349293,
"duplicate_report_number": "155555"
}
Report flagged as NOT a duplicate by LLM
Poor performance when joining rigs, if action constraints are present anywhere in the scene
https://projects.blender.org/blender/blender/issues/153288
System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4080 SUPER NVIDIA Corporation NVIDIA 591.74 Vulkan Backend
Blender Version
Broken: version: 5.0.1, branch: blender-v5.0-release, commit date: 2025-12-15 16:36, hash:
a3db93c5b259Worked: (newest version of Blender that worked as expected)
Short description of error
When joining two armature objects together, Blender can take an incredibly long time if a separate, unrelated third armature exists. This third armature must have action constraints with actions assigned.
This is a huge issue when generating a rig with rigify, if a more refined rig exists that makes use of action constraints.
Then the generation can take several minutes instead of seconds.
I have tried to break down the issue more, but haven't been lucky so far.
You can find an attached blend file where I've been able to reproduce the issue consistently.
Exact steps for others to reproduce the error
Version with performance issues
Version without performance issues
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps.
Bug report 1 is about playback performance with two rigify armatures: 4.x has 20fps, 5.0 has 10fps. Also mentions global undo issues when there are many duplicates of the rig.
Bug report 2 is about poor performance when joining rigs (armature objects) if another unrelated armature with action constraints exists. The steps involve joining two armatures and a third one with action constraints causing slowdown.
The key here is the core issue: Report 1 is playback speed, Report 2 is join operation speed. Different actions (playback vs joining), different contexts (multiple rig duplicates vs action constraints). So they're not the same issue. Therefore, answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 13.558004,
"duplicate_report_number": "153288"
}