利用者:TheBusyTypist/GSoC2016-Mesh-Undo-Memory
目次
Overview
Name: Ounan Ding
E-mail: ounanding@gmail.com
IRC: TheBusyTypist
GitHub: https://github.com/thebusytypist
Blog: http://blender.linearconstraints.net
There is a PDF version of this proposal, which has better typesetting: https://github.com/thebusytypist/gsoc-2016-doc/raw/master/proposals/mesh-undo-memory/mesh-undo-memory.pdf
Synopsis
I propose to optimize the memory usage of mesh undo.
Benefits to Blender
This project will reduce the memory usage and makes editing on detailed meshes easier.
Moreover, I will also take this chance to write or to improve the documentation on Blender operator system and operation history mechanism.
Deliverables
This project allows artists edit larger mesh object before hitting the memory limitation. The modification on the source code will be transparent to the artists.
Project Details
In this section I will first review the current implementation of mesh undo mechanism, and discuss the potential issues of it. After that I propose several optimization ideas and estimate a preliminary project schedule.
Review of Current Implementation
In Blender, all operations on mesh object are encapsulated as Blender Operators. And whenever an Operator is successfully executed, a snapshot of the current state will be captured and stored into the operation history.
I have a blog post[1] on the details of the undo mechanism. Generally speaking, the operation history is stored in a list undobase. And current state, which is a UndoElem structure, is pushed into the operation history.
UndoElem contains several function pointers to be filled by specific object types. These functions handles how current state is retrieved, duplicated to the operation history, and how it is restored and release on an undo command given by user. In fact, this is the polymorphism in C style.
For mesh data, the override functions are provided in editmesh_utils.c. The current strategy is that the whole mesh data get duplicated and restored on the undo command, which requires a lot of memory for a very detailed mesh object.
Design
According to our analysis on the current implementation, we can see that the general optimization direction is to avoid doing the complete duplication.
Moreover, each Operator itself has the best knowledge of how will it modify the mesh data and how will the result mesh data be different than the input one. So we want to allow programmer customize the undo strategy for different Operators in order to achieve the optimal memory usage.
Concretely, I propose following design:
- The set of function pointers in UndoElem will be move to wmOperatorType, where the programmer defines a wmOperator. Thus the programmer can provide a custom undo strategy for specific Operator. We call this set of functions as "undo functions".
- We pass the undo functions through ED_undo_push, to undo_push_mesh, where the UndoElem gets assembled. Thus the custom undo strategy can be dispatched dynamically.
- We also have a code path that when no custom undo strategy is provided by an Operator, we fall back to the default behavior: make a complete replica and restore the memory on undo command.
After we refactor the Operator/undo system, we can consider the specific undo strategies now.
For Operators which exhibit locality in their behavior, we can store the delta data only. This will reduce the memory usage dramatically.
Project Schedule
In the first two weeks I will refactor on the Operator/undo system, which is proposed above. In this stage only default undo strategy is used. We will perform tests to ensure nothing is broken in the refactoring. The memory usage will also be recorded as the baseline for later benchmarking.
After that I start to implement the specific undo strategies for individual Operators. We also propose new strategies while we are proceeding. We will iterate rapidly in this second stage.
Bio
Currently I am a master student from University of California, Riverside. In my previous job I was in charge of a particle system editor with fully undo/redo support. I run a blog[2] on Blender development. I have some articles about Blender operator and operation history system there.