Hi Campbell, Thank you for your clarification.
I just re-check the code but I am afraid I cannot confirm what you said. If I understand the code correctly, the actual assembling of UndoElem happens in undo_editmode_push. Then it steps in editbtMesh_to_undoMesh through: curundo->undodata = curundo->from_editmode(editdata, obedit->data); In the editbtMesh_to_undoMesh, I see verts, edges, loops are duplicated in the function BM_mesh_bm_to_me. I failed to find any difference checking code in BM_mesh_bm_to_me. It just iterates verts, edges, loops and copy the data. I am also aware of the member elem_index_dirty in BMesh. But I do not see it is used to avoid unnecessary copying. Please correct me if I am wrong. BTW, could you also put some comments on another proposal on Solidify modifier I wrote a day before? http://lists.blender.org/pipermail/bf-committers/2016-March/046915.html It is not hurry. But I really like to collect ideas and make some improvements before the final proposal submission date. Thank you. On Sat, Mar 5, 2016 at 8:27 PM, Campbell Barton <[email protected]> wrote: > On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding <[email protected]> wrote: > > Hi, > > > > I am Ounan Ding(IRC: TheBusyTypist). > > I am interested in Blender and willing to contribute to our community in > > the coming GSoC 2016. > > > > Here is my preliminary proposal to optimize the memory usage of mesh > undo: > > > > > > > https://github.com/thebusytypist/gsoc-2016-doc/raw/master/proposals/mesh-undo-memory/mesh-undo-memory.pdf > > Checked over the document, one thing which isn't quite correct is the > statement that... > > "The current strategy is that the whole mesh data get duplicated and > restored > on the undo command" > > ... in fact each chunk of memory is compared and only stored if there > are differences, > though this is inefficient when making destructive changes to the mesh > (subdivision for example), > it does mean changing selection won't have to store UV's, weights, > shape-keys etc. > > One possible optimization would be to implement binary diffing, so > minor differences to large allocates don't have to store the entire > block each time. > > > (and I put it on wiki.blender.org as well: > > > http://wiki.blender.org/index.php/User:TheBusyTypist/GSoC2016-Mesh-Undo-Memory > > But I suggest to read above pdf version since it has better typesetting) > > > > I have a review of current implementation here: > > http://blender.linearconstraints.net/2016/02/28/notes-on-undo.html > > It helps me form this proposal. > > > > I also have some notes and practice on the Blender Operator system: > > > http://blender.linearconstraints.net/2015/03/28/write-first-blender-operator.html > > > http://blender.linearconstraints.net/2015/04/01/analyze-primitive-cube-add-operator.html > > which lead me to the design in my proposal. > > > > Currently I am still working on more strategies for specific Operators. > > I am also looking forward to commends and critiques from you. > > > > Thank you. > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
