Repeated hiding and unhiding of objects causes more memory usage #59525
Labels
No Label
Priority
High
Priority
Low
Priority
Normal
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Content
Type
Design
Type
Report
Type
To Do
Type
Web Development
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: studio/blender-studio#59525
Loading…
Reference in New Issue
Block a user
No description provided.
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?
System Information
Operating system: Windows
Graphics card: GTX 960
Blender Version
Broken: 2.80
9149e894210
Short description of error
Repeated hiding and unhiding of objects causes Blender's total memory usage to rise. Higher numbers of objects (presumably also polycounts) have a larger impact.
Exact steps for others to reproduce the error
Repeatedly hide and unhide any number of objects in the viewport - I used the eye icon in the Outliner.
Added subscriber: @frameshift
Added subscriber: @ideasman42
This adds undo steps which use memory, unless the memory usage increased significantly since 2.7x it's not a bug.
Fair enough, makes sense.
Is it normal though for undo steps to take up more memory when the complexity of said objects increases? Even if the datablocks are linked from another library?
A cube, for example, adds kilobytes. A forest of linked trees adds tens of megabytes each time.
Added subscriber: @ZedDB
IIRC, the undo system save snapshots of the scene data (not diffs). So the more complex objects will add more to memory, yes.
Changed status from 'Open' to: 'Archived'
Right, there are snapshots but only changed chunks of memory are stored.
Did a quick comparison and it seems this isn't working especially differently in 2.8x compared to 2.7x. Closing.
@frameshift - if you can show an example where this is significantly worse in 2.8x compared to 2.79 release. Open a new report with sample file.