[Bf-blender-cvs] [d68d4e60ad7] undo-experiments-remap-history: Undo: Initial wip useless to handle ID pointers issues through more mappings.

[Bastien Montagne]

Commit: d68d4e60ad759fde12f05bd4b68058b4ce5ef654
Author: Bastien Montagne
Date:   Fri Nov 29 15:38:02 2019 +0100
Branches: undo-experiments-remap-history
https://developer.blender.org/rBd68d4e60ad759fde12f05bd4b68058b4ce5ef654

Undo: Initial wip useless to handle ID pointers issues through more mappings.

Don't think this is a working solution in fact, for at least two
reasons:
* Chaining Undo and Redo steps in random paterns with some ID being
reused and others being new all the time would require a very complex
system to keep track of all those changes and keep being able to remap
properly pointers from unread datablocks the the right new memory of
read datablocks.
* As small as it is, there is a risk of pointer collision here, and I
cannot see how to 100% handle it safely and sanely.

===================================================================

M	source/blender/blenloader/intern/readfile.c
M	source/blender/blenloader/intern/readfile.h

===================================================================

diff --git a/source/blender/blenloader/intern/readfile.c b/source/blender/blenloader/intern/readfile.c
index a8358a97732..7eb32ca444e 100644
--- a/source/blender/blenloader/intern/readfile.c
+++ b/source/blender/blenloader/intern/readfile.c
@@ -1587,6 +1587,9 @@ void blo_filedata_free(FileData *fd)
     if (fd->libmap && !(fd->flags & FD_FLAGS_NOT_MY_LIBMAP)) {
       oldnewmap_free(fd->libmap);
     }
+    if (fd->libmap_undo) {
+      oldnewmap_free(fd->libmap_undo);
+    }
     if (fd->bheadmap) {
       MEM_freeN(fd->bheadmap);
     }
@@ -1802,6 +1805,13 @@ static void *newpackedadr(FileData *fd, const void *adr)
 /* only lib data */
 static void *newlibadr(FileData *fd, const void *lib, const void *adr)
 {
+  if (fd->memfile != NULL && fd->libmap_undo != NULL) {
+    void *ret = oldnewmap_liblookup(fd->libmap, adr, lib);
+    if (ret == NULL) {
+      ret = oldnewmap_liblookup(fd->libmap_undo, adr, lib);
+    }
+    return ret;
+  }
   return oldnewmap_liblookup(fd->libmap, adr, lib);
 }
 
@@ -6295,6 +6305,7 @@ static void lib_link_collection_data(FileData *fd, Library *lib, Collection *col
 {
   for (CollectionObject *cob = collection->gobject.first, *cob_next = NULL; cob; cob = cob_next) {
     cob_next = cob->next;
+    Object *ob_prev = cob->ob;
     cob->ob = newlibadr_us(fd, lib, cob->ob);
 
     if (cob->ob == NULL) {
diff --git a/source/blender/blenloader/intern/readfile.h b/source/blender/blenloader/intern/readfile.h
index 93715d01458..d94d10b3b63 100644
--- a/source/blender/blenloader/intern/readfile.h
+++ b/source/blender/blenloader/intern/readfile.h
@@ -113,6 +113,20 @@ typedef struct FileData {
   struct OldNewMap *datamap;
   struct OldNewMap *globmap;
   struct OldNewMap *libmap;
+  /* We need a different mapping in undo case, when we are re-using some datablocks while getting
+   * new-from-file data for others, after the first step there is no way to tell where is that new
+   * ID from current, unchanged data (because we now have to deal with three different pointers
+   * for that new ID: the original one before any undo [stored in mem .blend file], the one after
+   * the first undo step [which is now used by other IDs from current bmain, that we want to
+   * re-use], and the new one from current undo step).
+   *
+   * `libmap` will only have the `original -> new` pointers, so we need to store the
+   * `from_previous_undostep -> new` pointers in another mapping.
+   *
+   * There is a little risk of collision here,
+   * will have to investigate wthere we can avoid that, or at the very least detect it and swicth
+   * back to a full proper read from memfile then... */
+  struct OldNewMap *libmap_undo;
   struct OldNewMap *imamap;
   struct OldNewMap *movieclipmap;
   struct OldNewMap *scenemap;