Changing Screen Scaling in Preferences causes a Grid Settings change which overwrites undone history states.

[oceanhahn]

If you change your Screen Scaling (possibly also UI scaling) rate in Preferences, it adds a Grid Settings change to your Undo History at least once at the document's current Undo state position. Normally this would occur at the most recent state and no Redo data would be lost, but in cases where a user has left their current Workspace undone or redone in a temporary position, they are liable to discover to their horror that their "temporary" undo state has been rendered permanent by an unexpected, unexpectable new Undo state.

A quick solution might be to apply a simple confirmation dialogue box to Screen Scaling changes if any Workspaces (with more than one Undo state) are currently open, warning the user that changing the Screen Scaling rate will cause undone history changes to be unrecoverably lost (at least if Non-Linear History is disabled) and to make sure their Workspace(s) are at their most-recent undo state to prevent any loss of data. The Screen Scaling change could be approved or cancelled from there.

It is rare that it will come up, but the addition of a simple ok/cancel box that might take maybe ten minutes to implement and test could prevent the loss of potentially hours of unrecoverable work per incident (especially given that Undo histories are not preserved by saving or Recovery states).

Curiously, the Screen Scaling change only seems to affect a Grid Settings change (or at least one which creates a new history state) to the current active Workspace, even if other Workspaces are open but do not have focus. It is entirely possible that the Grid Settings change is a bug (vestigial or accidental) in the first place and may be safely removed.

Anyway thank you for looking into it! :D

..using ASEprite v.1.3-beta16-x64 on Win10.

[dacap]

Hi @oceanhahn, thanks for reporting this. I think this is a bug. Generally the preferences dialog shouldn't delete the redo history, and the only occasion this could happen is when the Grid settings are changed. But even in this case I don't know if the redo history should be changed i.e. should grid settings changes be stored in the undo history? (I think yes, so maybe in this case we could show a warning if there is some redo information to clear).

In a near future we would like to:

1. store some undo information in the .aseprite file (optionally), related to Save/restore the whole session (+undo information) automatically #1324 and
2. give a better undo/redo history management where the redo information (with all their branches) is persistent, so this would enable an optional way to see the "Undo History" window in a "Tree-like View"

Even more, when the redo information is destroyed, I think a little warning should be displayed in some place where clicking it would show this tree-like undo history where we can jump around different redo histories.