This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/editors/undo/memfile_undo.c

311 lines
9.5 KiB
C
Raw Normal View History

/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
/** \file
* \ingroup edundo
*
* Wrapper between 'ED_undo.h' and 'BKE_undo_system.h' API's.
*/
#include "BLI_sys_types.h"
#include "BLI_utildefines.h"
#include "BLI_ghash.h"
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
#include "DNA_node_types.h"
#include "DNA_object_enums.h"
#include "DNA_object_types.h"
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
#include "DNA_scene_types.h"
#include "BKE_blender_undo.h"
#include "BKE_context.h"
#include "BKE_lib_id.h"
#include "BKE_lib_query.h"
#include "BKE_main.h"
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
#include "BKE_node.h"
#include "BKE_scene.h"
#include "BKE_undo_system.h"
#include "../depsgraph/DEG_depsgraph.h"
#include "WM_api.h"
#include "WM_types.h"
#include "ED_object.h"
#include "ED_undo.h"
#include "ED_util.h"
#include "../blenloader/BLO_undofile.h"
#include "undo_intern.h"
/* -------------------------------------------------------------------- */
/** \name Implements ED Undo System
* \{ */
typedef struct MemFileUndoStep {
UndoStep step;
MemFileUndoData *data;
} MemFileUndoStep;
static bool memfile_undosys_poll(bContext *C)
{
/* other poll functions must run first, this is a catch-all. */
if ((U.uiflag & USER_GLOBALUNDO) == 0) {
return false;
}
/* Allow a single memfile undo step (the first). */
UndoStack *ustack = ED_undo_stack_get();
if ((ustack->step_active != NULL) && (ED_undo_is_memfile_compatible(C) == false)) {
return false;
}
return true;
}
static bool memfile_undosys_step_encode(struct bContext *UNUSED(C),
struct Main *bmain,
UndoStep *us_p)
{
MemFileUndoStep *us = (MemFileUndoStep *)us_p;
/* Important we only use 'main' from the context (see: BKE_undosys_stack_init_from_main). */
UndoStack *ustack = ED_undo_stack_get();
if (bmain->is_memfile_undo_flush_needed) {
ED_editors_flush_edits_ex(bmain, false, true);
}
/* can be NULL, use when set. */
MemFileUndoStep *us_prev = (MemFileUndoStep *)BKE_undosys_step_find_by_type(
ustack, BKE_UNDOSYS_TYPE_MEMFILE);
us->data = BKE_memfile_undo_encode(bmain, us_prev ? us_prev->data : NULL);
us->step.data_size = us->data->undo_size;
/* Store the fact that we should not re-use old data with that undo step, and reset the Main
* flag. */
us->step.use_old_bmain_data = !bmain->use_memfile_full_barrier;
bmain->use_memfile_full_barrier = false;
return true;
}
static int memfile_undosys_step_id_reused_cb(LibraryIDLinkCallbackData *cb_data)
{
ID *id_self = cb_data->id_self;
ID **id_pointer = cb_data->id_pointer;
BLI_assert((id_self->tag & LIB_TAG_UNDO_OLD_ID_REUSED) != 0);
ID *id = *id_pointer;
if (id != NULL && id->lib == NULL && (id->tag & LIB_TAG_UNDO_OLD_ID_REUSED) == 0) {
bool do_stop_iter = true;
if (GS(id_self->name) == ID_OB) {
Object *ob_self = (Object *)id_self;
if (ob_self->type == OB_ARMATURE) {
if (ob_self->data == id) {
BLI_assert(GS(id->name) == ID_AR);
if (ob_self->pose != NULL) {
/* We have a changed/re-read armature used by an unchanged armature object: our beloved
* Bone pointers from the object's pose need their usual special treatment. */
ob_self->pose->flag |= POSE_RECALC;
}
}
else {
/* Cannot stop iteration until we checked ob_self->data pointer... */
do_stop_iter = false;
}
}
}
return do_stop_iter ? IDWALK_RET_STOP_ITER : IDWALK_RET_NOP;
}
return IDWALK_RET_NOP;
}
static void memfile_undosys_step_decode(struct bContext *C,
struct Main *bmain,
UndoStep *us_p,
int undo_direction,
bool UNUSED(is_final))
{
BLI_assert(undo_direction != 0);
bool use_old_bmain_data = true;
if (USER_EXPERIMENTAL_TEST(&U, use_undo_legacy)) {
use_old_bmain_data = false;
}
else if (undo_direction > 0) {
/* Redo case.
* The only time we should have to force a complete redo is when current step is tagged as a
* redo barrier.
* If previous step was not a memfile one should not matter here, current data in old bmain
2020-03-19 12:05:34 +11:00
* should still always be valid for unchanged data-blocks. */
if (us_p->use_old_bmain_data == false) {
use_old_bmain_data = false;
}
}
else {
/* Undo case.
2020-03-19 12:05:34 +11:00
* Here we do not care whether current step is an undo barrier, since we are coming from
* 'the future' we can still re-use old data. However, if *next* undo step
2020-03-18 22:28:54 +11:00
* (i.e. the one immediately in the future, the one we are coming from)
* is a barrier, then we have to force a complete undo.
* Note that non-memfile undo steps **should** not be an issue anymore, since we handle
* fine-grained update flags now.
*/
UndoStep *us_next = us_p->next;
if (us_next != NULL) {
if (us_next->use_old_bmain_data == false) {
use_old_bmain_data = false;
}
}
}
/* Extract depsgraphs from current bmain (which may be freed during undo step reading),
* and store them for re-use. */
GHash *depsgraphs = NULL;
if (use_old_bmain_data) {
depsgraphs = BKE_scene_undo_depsgraphs_extract(bmain);
}
ED_editors_exit(bmain, false);
MemFileUndoStep *us = (MemFileUndoStep *)us_p;
BKE_memfile_undo_decode(us->data, undo_direction, use_old_bmain_data, C);
for (UndoStep *us_iter = us_p->next; us_iter; us_iter = us_iter->next) {
if (BKE_UNDOSYS_TYPE_IS_MEMFILE_SKIP(us_iter->type)) {
continue;
}
us_iter->is_applied = false;
}
for (UndoStep *us_iter = us_p; us_iter; us_iter = us_iter->prev) {
if (BKE_UNDOSYS_TYPE_IS_MEMFILE_SKIP(us_iter->type)) {
continue;
}
us_iter->is_applied = true;
}
/* bmain has been freed. */
bmain = CTX_data_main(C);
ED_editors_init_for_undo(bmain);
if (use_old_bmain_data) {
/* Restore previous depsgraphs into current bmain. */
BKE_scene_undo_depsgraphs_restore(bmain, depsgraphs);
/* We need to inform depsgraph about re-used old IDs that would be using newly read
* data-blocks, at least COW evaluated copies need to be updated... */
ID *id = NULL;
FOREACH_MAIN_ID_BEGIN (bmain, id) {
if (id->tag & LIB_TAG_UNDO_OLD_ID_REUSED) {
BKE_library_foreach_ID_link(
bmain, id, memfile_undosys_step_id_reused_cb, bmain, IDWALK_READONLY);
}
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
2020-04-08 10:33:56 +10:00
/* Tag depsgraph to update data-block for changes that happened between the
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
* current and the target state, see direct_link_id_restore_recalc(). */
if (id->recalc) {
DEG_id_tag_update_ex(bmain, id, id->recalc);
}
}
FOREACH_MAIN_ID_END;
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
FOREACH_MAIN_ID_BEGIN (bmain, id) {
/* Clear temporary tag. */
id->tag &= ~LIB_TAG_UNDO_OLD_ID_REUSED;
/* We only start accumulating from this point, any tags set up to here
* are already part of the current undo state. This is done in a second
* loop because DEG_id_tag_update may set tags on other datablocks. */
id->recalc_after_undo_push = 0;
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
bNodeTree *nodetree = ntreeFromID(id);
if (nodetree != NULL) {
nodetree->id.recalc_after_undo_push = 0;
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
}
if (GS(id->name) == ID_SCE) {
Scene *scene = (Scene *)id;
if (scene->master_collection != NULL) {
scene->master_collection->id.recalc_after_undo_push = 0;
Undo: change depsgraph recalc flags handling to improve performance These changes only have an effect when the experimental Undo Speedup preference is enabled. * For DEG_id_tag_update, accumulate recalc flags immediately before the undo push happens instead of afterwards. Otherwise the undo state does not contain enough flags, and the current state may contain too many flags. This also means we call DEG_id_tag_update after undo with the accumulated flags to ensure they are flushed to other datablocks. * For undo, accumulate recalc flags in id->recalc and clear accumulated flags immediately. Not clearing would cause circular behavior where accumulated flags may never end up being cleared. This matches what happens after an undo push where these are also cleared, indicating that the undo state and current in-memory state match exactly. * Don't change id->recalc of identical datablocks, it should not be needed. There is one exception for armatures where pointers across datablocks exist which otherwise would cause problems. There may be a better solution to this but it seems to work in agent 327 production files. * This contains a change in undofile.c to avoid detecting all datablocks as changed for the first of the two undo steps, where we restore to the state of the last undo push before going to the one before. Without this the whole system is much less efficient. However this is unsafe in the sense that if an app handler or operators edits a datablock after an undo push, that change will not be undone. It can be argued that this is acceptable behavior, since a following undo push will include that change and this may already have unexpected side effects. Ref T60695 Differential Revision: https://developer.blender.org/D7339
2020-04-04 19:30:42 +02:00
}
}
}
FOREACH_MAIN_ID_END;
}
WM_event_add_notifier(C, NC_SCENE | ND_LAYER_CONTENT, CTX_data_scene(C));
}
static void memfile_undosys_step_free(UndoStep *us_p)
{
/* To avoid unnecessary slow down, free backwards
* (so we don't need to merge when clearing all). */
MemFileUndoStep *us = (MemFileUndoStep *)us_p;
if (us_p->next != NULL) {
UndoStep *us_next_p = BKE_undosys_step_same_type_next(us_p);
if (us_next_p != NULL) {
MemFileUndoStep *us_next = (MemFileUndoStep *)us_next_p;
BLO_memfile_merge(&us->data->memfile, &us_next->data->memfile);
}
}
BKE_memfile_undo_free(us->data);
}
/* Export for ED_undo_sys. */
void ED_memfile_undosys_type(UndoType *ut)
{
ut->name = "Global Undo";
ut->poll = memfile_undosys_poll;
ut->step_encode = memfile_undosys_step_encode;
ut->step_decode = memfile_undosys_step_decode;
ut->step_free = memfile_undosys_step_free;
ut->use_context = true;
ut->step_size = sizeof(MemFileUndoStep);
}
/** \} */
/* -------------------------------------------------------------------- */
/** \name Utilities
* \{ */
/**
* Ideally we wouldn't need to export global undo internals,
* there are some cases where it's needed though.
*/
static struct MemFile *ed_undosys_step_get_memfile(UndoStep *us_p)
{
MemFileUndoStep *us = (MemFileUndoStep *)us_p;
return &us->data->memfile;
}
struct MemFile *ED_undosys_stack_memfile_get_active(UndoStack *ustack)
{
UndoStep *us = BKE_undosys_stack_active_with_type(ustack, BKE_UNDOSYS_TYPE_MEMFILE);
if (us) {
return ed_undosys_step_get_memfile(us);
}
return NULL;
}
/** \} */