[Bf-committers] GSoC 2016 Preliminary proposal to optimize the memory usage of mesh undo

[Campbell Barton]

On Sun, Mar 6, 2016 at 4:53 PM, Ounan Ding <ounanding at gmail.com> 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 <ideasman42 at gmail.com>
> wrote:
>
>> On Sat, Mar 5, 2016 at 8:19 PM, Ounan Ding <ounanding at gmail.com> 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
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell