Flush edit and sculpt modes for autosave #110088

Joseph Eagar · 2023-07-14T03:32:40+02:00

Joseph Eagar commented

2023-07-14 03:32:40 +02:00

This is a reimplementation of the hack I did in temp-sculpt-dyntopo to attract testers. It flushes editmode/sculpt mode during autosave. It works for everything except text objects. I had to write a function to safely encode a memfile step without changing state in the undo stack, but it seems to work.

Joseph Eagar added 2 commits 2023-07-14 03:32:48 +02:00

55e6c2cb7a Core: Flush edit modes on autosave

31a49dbdef Add function to safely extend a memfile without modifying

the undo stack state, ED_undosys_stack_memfile_encode_clean.

Joseph Eagar requested review from Campbell Barton 2023-07-17 19:01:56 +02:00

Sergey Sharybin commented

2023-07-25 10:55:25 +02:00

This topic pops up every now and then, and the unfortunate aspect of it is that it is more complicated that it seems.

Such flushing is not necessarily cheap (time-wise) to do. So doing so will introduce a lag for artists: some strokes will be "eaten" or heavily delayed because the system is busy performing the flush and autosave. If i remember correctly, this is an exact issue of what was driving artists crazy here during the Spring project when the undo system did undergo redesign for 2.80.

Additionally, the reality is that flushing of both shapekeys and multires changes might have unreversible consequences. Surely, it would be awesome to get those addressed, but to me it is a factor which needs to be taken into account when working on functionality like this.

Ideally, the auto-save will never interfere with artists. There are two ways to explore is see:

Somehow benefit from implicit sharing, so that we do not need to have the auto-save a locking operation from the users perspective
Allow saving edit-mode state to autosave file.

Those are not mutually exclusive points: doing less to be able to save autosave.blend is always good, but even if we do less then it is still good to do in a non-locking manner.

This topic pops up every now and then, and the unfortunate aspect of it is that it is more complicated that it seems. Such flushing is not necessarily cheap (time-wise) to do. So doing so will introduce a lag for artists: some strokes will be "eaten" or heavily delayed because the system is busy performing the flush and autosave. If i remember correctly, this is an exact issue of what was driving artists crazy here during the Spring project when the undo system did undergo redesign for 2.80. Additionally, the reality is that flushing of both shapekeys and multires changes might have unreversible consequences. Surely, it would be awesome to get those addressed, but to me it is a factor which needs to be taken into account when working on functionality like this. Ideally, the auto-save will never interfere with artists. There are two ways to explore is see: * Somehow benefit from implicit sharing, so that we do not need to have the auto-save a locking operation from the users perspective * Allow saving edit-mode state to autosave file. Those are not mutually exclusive points: doing less to be able to save autosave.blend is always good, but even if we do less then it is still good to do in a non-locking manner.

Sergey Sharybin requested review from Julien Kaspar 2023-07-25 10:56:14 +02:00

Dalai Felinto referenced this pull request

2023-07-27 12:22:47 +02:00

WIP: Sculpt: dynamic topology refactor #104613

Joseph Eagar referenced this pull request

2023-08-31 20:42:52 +02:00

WIP: Sculpt: dynamic topology refactor #104613

This pull request has changes conflicting with the target branch.