高中,读过几本 3D 图形编程相关的书。怎么说呢,自那以后,图形学相关的东西,都不在我的兴趣范围里了。直到最近,我重新燃起了一点兴趣:
-
架构治理工具 ArchGuard 依赖于「图即代码」,用于生成架构图,以更好的进行架构治理。
年初,开源的知识管理工具 Quake 中,需要支持「概念构建系统」这样一个理念。
需要管理多种不同的图形格式。
当然了,作为一个 Firefox 浏览器的忠实用户,Firefox 在 Feakin 里自然是支持最好的。开始之前,欢迎尝试在线 Demo:https://online.feakin.com/ , GitHub:https://github.com/feakin/feakin/,当然了 Bug 超级多。
引子:开源绘图工具实现的浅析
在设计 Feakin 的时候,参考了一些几个常用的图形工具。分析了它们的大致实现,以及部分的源码:
Graphviz
AT&A 实验室的作品,作为最古老的图形即代码的工具,它还提供了一个图形描述语言:Dot,可以直接将代码转换为图形。它的生态体系足够的完善,所以你在哪都能看到它的影子。
Mermaid
同样也是一个图形即代码的工具,使用的是纯 JavaScript 实现,从语法解析到图形渲染。Mermaid 使用 Jison 作为解析器,然后将其转换为不同的图模型,如流、时序等,再使用 graphlib、dargre 进行布局,最后使用 dagre-d3、d3 进行渲染。因此,在 Mermaid 里有三个核心要素:语法解析、图形布局、图形渲染。而,Mermaid 不存在一个图形模型,也变成了一个神奇的存在。
Cytoscape
第一次看到这个图形引擎的时候,是看到 ArchGuard 前人留下的一个功能:布局算法切换。所以,在源码实现上,Cytoscape 提供了这种算法上的扩展性,具体可以看官方网站。布局上的抽象,提供了更好的可扩展性 —— 我们就可以参考它的实现了。在它的图形模型里,Node(节点) 和 Edge(边) 从形式上都算是 Element,然后在渲染时根据图形类型展开。于是在渲染时,直接采用 HTML5 里的 Canvas 进行绘制即可。
Excalidraw
对我来说,其最有意思的是引入了射影几何,来进行节点变化时的,自动 Edge 跟踪;即当 A 从 B 的左边移动到右边时,对应的线自动连接到 B 右边的边上。当然了,其中的各种神奇算法,我也没看懂。对于其他人,可能就是使用 roughjs 来生成手绘风格的图。当然了, 就目前的代码实现来说,roughjs 在 renderElement 里过度的耦合,图形模型也耦合在其中。
MaxGraph
MaxGraph 是 Draw.io 底层的 mxGraph 的 TypeScript 实现,最开始研究时,是为了导入 Draw.io 生成的图。从模型上来说,MaxGraph 应该是几个工具里做得最好的,包含一系列的可参考的 Shape、Edge 等等。其次,也提供了 AbstractCanvas2D 这样的实现,虽然它没有实现真正的 HTML5 Canvas2D,但是抽象接口已经非常像了,诸如 .moveTo
、.lineTo
等。可能它就提供 SVG 和 XML,前者用于网页渲染,后者用于导出。
所以,从上述的几个工具里,我们就能得到一个绘图工具底层的基本要素:
-
图形模型。即对图形建模,理清 Diagram/Graph、Node、Edge、Shape、Element 之间的关系,并包含基本的图形表示关系。
图形绘制。即定义如何对图形进行绘制/渲染,如采用 SVG、Canvas 等不同的形式。
为了丰富这些功能:
-
布局算法。提供自动化的布局方式,如 Cytoscape 这一类自动计算的方式。
语法解析。诸如于为了支持图即代码(即 DSL)的形式来提供快捷的绘制方式。
自动连线。即如 Excalidraw、Draw.io 中提供的功能,两者实现的方式完全不一样。
图形风格。诸如于 Excalidraw 提供的手绘图形的功能。
图形库。这也是 Drawio 最受欢迎的地方,也是 Excalidraw 一个很有意思的功能。
等等
结合这些功能,我们就可以造出一些有意思的东西,比如 Feakin 中的二阶段渲染。
Step 1:实现第一个概念证明
为了 Feakin 能进行下去,我们所要做的就是快速实现一个 PoC(概念证明)。在这个 PoC 里,主要实现如下的功能:
-
DSL (领域特定语言)解析。
图形模型生成。
图形绘制。
如下图所示:
这样一来,我们就有一个「It works」了。
从图形引擎的误区中出来
在实现第一个 PoC 的时候,遇到的第一个困难是技术选型,到底是:SVG 还是 Canvas?SVG 可以方便于我们进行 TDD(测试驱动开发),只要所有的测试是通过的,理论上结果就是过的。但是,如我们所看到的那样,SVG 容易遇到性能瓶颈。Canvas 提供自由的绘制 API,测试时依赖于快照测试(snapshot),不易于编写测试。所以,结论就是:我们都要了吧。只需要像 MaxGraph 提供一个抽象图形接口,我们就能实现对于两种模式的支持。
随后,发现这样是不合理的,只在 PoC 阶段,并且没有经验的情况下,做一个 AbstractCanvas 还是存在很高的成本。于是乎,需要寻找一个合理的绘制引擎,诸如于 Raphaël、Fabric、Konva 等。最后,选择了 Konva,因为它支持了 React 框架。正所谓,工作用 Angular 心不累,业余用 React 放我自我。
原型:语法解析-图形模型-图形绘制
在构建了基本的图形领域的相关知识之后,要构建出一个绘图工具并不困难。
-
参考(复制) Mermaid 的语法解析。将通过 parser 解析类似于 Graphviz、Mermaid 设计的语法,将其转换为图形模型。
引入 Dagre.js 作为图形布局引擎。通过 Dagre.js 来计算布局,返回我们所需要的图形模型。
使用 React Konva 进行渲染。将图形模型匹配到 Konva 中的图形,如 RectangleShap 对应于
<Rect>
组件、Edge 对应于<Line>
、<Arrow>
等。
过程中,遇到的一个比较坑的点是:Lerna Nx.js 管理 monorepo。React Craco 的组合、风格各异的代码库,带来了持续失败的 CI,还好 GitHub Action 不会统计失败率。持续集成不来点失败,怎么能发挥它的用处呢。
Step 2:对模型进行反复重构(持续)
在 Poc 里,我们需要遇到不同的模型转换:
-
解析器获得的模型。包含节点的信息,以及节点的关系(诸如于 A 到 B、A 依赖于 B 等)。
布局引擎生成的模型。通常来说,只是补充一下模型里的层次关系(children/parent)、坐标信息(x、y)、几何信息(width、height)等。
图形绘制引擎的模型。我们需要将上述的信息,再次转换到 Konva 的模型中。而其中会存在一些差距,比如 Konva 使用 Polygon(多边型)来表示Triangle(三角型)、Diamond(菱形)等。
所以,如何设计一个有用的模型,成为了个有意思的问题。
GIM:图中间模型
在那一篇《图的抽象:概念与模型的构建》中,我们介绍了从认知语义学的角度,如何仅凭基本的概念,设计出可用的模型?不过,这样的模型是未经验证的。那么,什么样的模型是经常验证的呢?自然是开源社区中,已经充分使用的代码模型。虽然说,各个模型受限于自己的场景,与其他软件的模型存在一定的差距。但是呢,在基本的核心概念图的表示上,它们是大差不差的。于是乎,我们有了一个 GIM(Graph Intermedia Model),图中间模型。
这个图模型的来源是源自其他图形工具成熟的模型,如下图所示:
所以,在持续的建模、提炼之后,我们可以轻松地进行我们的图模型转换。在有了 TDD 的加持之后,这个过程就更加地简单了。
在模型这一点上,Feakin 的设计初衷与 ArchGuard 底层的 Chapi (https://github.com/modernizing/chapi) 语言模型的想法是一致的。而这种所谓的通用模型会遇到的问题是,需要抛弃一些细节,诸如于只实现 80% 的核心功能。
图的模型
对于一个图(Graph)来说,它的模型也就变得相当的简单:
-
export interface Graph {
nodes: Node;
edges: Edge;
props?: GraphProperty;
subgraphs?: Graph;
}
围绕于这四个核心元素再往下展开:
-
节点(Node)。主要包含坐标信息,形态信息等,可以用于构建出不同的 shape。
边(Edge)。主要包含点(Point),可以用于构建普通的直线、贝塞尔曲线(Bézier)曲线等,还有
属性(Props)。这里只属于命名为 props 是为了对齐 🐶 ,对应于图形属性,诸如于 fillColor、color、strokeColor 等。
子图(Graph[])。一个抽象的概念,在不同的图示中有不同的形式,如 Group、子集等。
而如上所述 Shape 和 Edge 就是两个大家庭,包含了一系列的子类,诸如于 Shape 包含了 PolygonShape(又包含了 TriangleShape、DiamondShape、RectangleShape 、HexagonShape)。
状态与属性(TBD)
对于属性来主,尚未进一步展开,但是初步分为:FillState、FontState、StrokeState、ImageState 等。
如果你也感兴趣的话,欢迎一起来设计。
Step 3:核心特性基础:二阶段绘图
在反复的设计了各种 Importer/Exporter 之后,并持续不断的进行模型重构之后,就构成了的核心特性的基础:二阶段绘图。简单来说,就是把绘图分为了两阶段:
-
通过 DSL 生成图或者导入生成图。
使用图形工具对生成的图进行编辑。
以在不同的工具之间转换,并实现图的互转。
二阶段绘图示例
在这里就可以尝试使用:https://online.feakin.com/ ,虽然还只是一个早期的版本,仍旧还有一系列的 bug,但是还可以尝试的。
如上图所示,我们可以
-
通过 File → Import 导入 Draw.io 或者 Excalidraw,又或者是通过 Graphviz 的 Dot 语法编写。
通过 Export 导出到 Draw.io 或者是 Excalidraw
图中,左边的编辑器是使用 Monaco Editor,配合了简单的 Dot 语法支持;右边则是一个早期版本的 Feakin Render,只能简单地渲染一下,看看效果。当前,仅支持简单的拖拉拽,还容易出错。
决策:过程一致或者结果一致?
在这个过程中,还有一系列有意思的东西,比如 Shape 在不同的图形工具是不一样的。先让我们看个代码示例:
-
digraph G {
a [shape=\"triangle\"];
b [shape=\"diamond\"];
a -> b;
}
也是截图中的代码简化,节点 a 的 shape 是一个 Triangle(三角形),然而:
-
在 Excalidraw 中不存在三角形,需要自己用 Line 绘制一个。
在 Draw.io 中默认的 Triangle 和正确的三角形不一样,正确的类似应该是
mxgraph.basic.acute_triangle
。
于是乎,为了结果上的一致,我们需要在对应的 ExcalidrawExporter、DrawioExporter 进行对应的 Shape 的处理和 Mapping。
Step 4:从 MVP 到真实世界
在这个 MVP(最小可行性产品)里,我们所构建的只是一个可以工作的原型,依旧有一系列的工作要完成。诸如于:
更丰富的图形
当前只支持基础的图形,在未来,支持其它工具的图形库 —— 有了 GIM,我们就不需要自己设计了。
图形的属性
从颜色到边框,一个功能也没有。难点主要在于,如何进行对应的属性抽象。在 MaxGraph 是一个胖模型,这种模型不利于维护,会带来额外的知识负载,它还是按字母顺序排序的,头疼。
生态兼容性
诸如于,虽然我们能成功导出 Excalidraw 的图形,也可以实现模型之间的绑定。但是,在一些属性上还是有区别的。
当然,这也是其中非常有意思的地方 —— 原来你只需要写一份未经验证的代码,现在你要看 N 份。
下一步:远程多人协作
除此,之前读过的 Xi Editor,也有关于 Rope 模型也有很好的介绍:https://xi-editor.io/docs.html。它提供了一个很好的 Rust 实现,这样一来,我们就可以使用 Rust 来开发 Feakin 的协作部分。
如果你也有兴趣,欢迎一起来用爱发电。如此一来,也不枉我花三个小时写的这篇文章。
在线 Demo:https://online.feakin.com/
GitHub:https://github.com/feakin/feakin/
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。