On Sun, Mar 6, 2016 at 4:53 PM, Ounan Ding <[email protected]> wrote: > 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.
No, your right, was thinking of global undo but re-read the code here and it does store entire mesh for each undo step. > 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 -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
