图形编辑器:历史记录设计

开发 前端
要记录图形编辑器的历史记录,支持撤销重做功能,需要两个栈:撤销(undo)栈和重做(redo)栈。

大家好,我是前端西瓜哥。今天讲一下图形编辑器如何实现历史记录,做到撤销重做。

其实就是版本号的更替。每个版本保存一个状态。

数据结构

要记录图形编辑器的历史记录,支持撤销重做功能,需要两个栈:撤销(undo)栈和重做(redo)栈。

每当用户进行一个操作(比如移动一个图形),就会产生一个新的版本,将这个操作产生的状态保持加入到 undo 栈顶,此外 redo 栈会清空。因为用户可能撤销了几次然后产生了新的操作,无法重做它们了。

当用户撤销,undo 栈出栈,并放到 redo 栈,然后使用 undo 栈顶的状态。当用户重做时,redo 栈出栈,再放到 undo 栈上,并应用 undo 栈顶的状态。

原理大概这样。

浏览器的回退前进的表现其实就是一个很常见的例子。

数据结构还有另一种方案:双向链表加两个指针,一个指针指向当前版本状态,另一个指针指向 redo 最后一次可执行到达的状态。

然后是如果要支持协同的场景,你的撤回不会回到之前的版本,而是将之前的版本的状态拿出来作为一个新的版本。

协同中你也不能撤回别人的操作,只能撤回自己的,并且要用协同算法处理和其他协同者的冲突逻辑。

要保存哪些状态

那么我们的状态要保存哪些状态呢?

  1. 图形树数据
  2. 图形树需要的引用
  3. 一些设置

图形树是必要的,我们需要用它渲染画布内容。此外还有游离在图形树之外的被用到的对象,比如图层、被多次引用的图形。你可以也把它们也放到图形树里面去。

最后是一些需要共享的设置,比如表格的行高、筛选条件等。

像是颜色主题、国际化语言设置则不需要历史记录,它是用户自己选择的个性化定制。

我们看具体的几种实现。

全量快照

每次操作得到的新状态,完全拷贝一份保存起来。

因为对象如果只是浅拷贝,其中的引用对象可能会被意外地修改,通常我们会选择 序列化成字符串 保存,即JSON.stringify。撤销重做的时候再解析出来作为当前状态。

优点是实现简单。巨大的优点。

缺点是当状态很大的时候,每次生成快照都会比较耗时,且操作很多产生很多版本时,需要大量的内存空间保存这些完整状态。

如果画布上有一万个独立的实体,就意味着每进行一次操作,就要将这个一万个实体深拷贝一份。100 次就是 100w,很恐怖。

仅推荐简单的图形编辑器使用,或者做 demo 用。

补丁(patch)

全量快照让编辑器的上限很低,不是最优解。

一种更好的解法,是 打补丁(patch)。

基于上一个版本 1,打一个补丁,变成下一个版本 2。同时我们记录一个反向的补丁,撤回的时候能通过它从版本 2 回到版本 1。

这个方案对应了设计模式的 命令模式,我们构建 Command 类,这个类有 execute、redo、undo 方法,这些方法会对传入的旧的状态对象打补丁,得到一个新的状态。

比如添加矩形命令,execute 和 redo 时我们会往图形树的末尾加一个矩形对象,undo 就是将这个矩形从图形树中移除。undo 栈和 redo 栈此时记录的就是一个个 command 对象了。

图片

纯纯用朴实无华的命令模式去实现,还是有点坑的。因为要实现的命令太多了,比如添加图形、修改图形属性、删除图形、对几个图形做右对齐等,这些都要自己一个个实现 redo 和 undo。复杂一点就要抓瞎,建议找一些轮子。比如 immer、y.js。

使用补丁方案还有一个好处,就是方便实现 “动作” 功能。(当然这不是一个优先级很高的功能)

比如我们想要给一个图形先顺时针旋转 45 度,然后向右移动 10 个单位,我们希望记录这两个操作,给其他图形也应用这些操作。

快照的方式就不好搞,或许我们可以对比新旧状态找不同推断出行为,但不好搞。因为属性的变化可能来自不同的操作,比如移动,可以通过移动工具相对位移产生,也可能直接属性面板改 x 值,也可能是通过对齐操作产生的。

patch 就很适合。

什么时候保存状态

我们需要确认一个操作完成的时刻,将它加入到历史记录中。

我们操作图形,会产生一些 中间状态。比如移动一个图形,拖拽的过程中不生产一个历史版本,直到拖拽结束才记录。

一种方式是:操作图形的替身,操作结束后才更新真正的状态。

一些编辑器,比如 Adobe Illustrator、AutoCAD,我们在操作图形的时候,会看到一个临时的替身,就是将被选中图形的轮廓线或拷贝做鼠标的跟随,鼠标释放后才真正修改图形属性。

还比如颜色的修改,在拾色器中挑选颜色时不会立即修改图形,在点击确认才真正修改图形显示在画布上。

图片

另一种方式是:直接操作真正的状态,在操作结束的时候,记录这个时刻的状态。

图片

第一种方式的好处是,状态没有中间状态,替身操作完,计算出新状态应用到真正的状态上就好了。

第二种方式就要额外在操作开始时,保存原始状态的快照,因为之后我们会产生中间状态,然后在操作结束后计算 patch。

但第二种方式用户体验会更好些,用户能实时看到一个图形的变化,判断是不是自己需要的效果,而不是看到一个 “通往未来的幻影”。

责任编辑:姜华 来源: 前端西瓜哥
相关推荐

2024-01-22 10:01:41

Git 提交快照

2009-08-20 16:25:05

Linux系统历史记录linux

2011-10-09 14:57:35

2021-04-27 15:38:10

GoogleChrome历史记录

2013-12-05 17:37:57

Windows 8文件历史记录

2022-01-25 11:33:14

数据泄露网络攻击

2013-01-21 14:37:05

Windows 8历史记录

2009-07-07 15:49:04

root命令历史记录安全性 

2021-01-06 18:10:22

ShellLoki系统运维

2021-12-15 23:33:33

Windows 11Windows微软

2017-03-27 16:15:42

ChromeVivaldi浏览器

2016-01-27 11:24:20

Windows 10红石镜像

2023-08-01 09:30:12

SQL Server数据库

2016-01-26 15:27:16

Windows 10历史记录备份

2021-01-20 09:29:09

QQ浏览器App

2023-10-19 10:12:34

图形编辑器开发缩放图形

2023-06-02 10:41:50

2019-10-14 16:16:49

BashLinux命令

2022-04-29 16:47:57

AI腾讯

2013-12-06 13:33:08

安全补丁
点赞
收藏

51CTO技术栈公众号