1. 前言
最近接手了一个编辑器项目，用fabric实现，这个项目在渲染数千个节点时，能明显感受到卡顿，于是作者想用pixijs来重构这个项目，在重构的过程中，会尽量对上层暴露于fabric类似的api，使得上层业务接入速度能够达到最快，并且，要尽可能地保留fabric原本的逻辑，否则，可能会使得节点的位置发生错位或者产生一些其他bug，所以，在重构的过程中，作者研究了一些fabric的源码，这也使得作者冒出了写一篇文章的想法，所以，这篇文章就出现了。
2. pixijs和fabricjs的区别
2.1 两个库的侧重点
pixijs是一个webGL渲染库，虽然也可以回退到canvas2D，但是我想大家使用pixi的时候肯定不会用canvas2D渲染的，所以，就当它是一个纯webGL渲染库吧。
pixijs是一个重渲染，轻交互的库，它本身不提供复杂的交互功能(像框选、拖拽等)，而是只提供了一些比较基础的东西，比如绘制一个基本图形、绘制一张图片，为图形绑定一个点击事件等，它注重于如何把用户提供的内容快速地渲染出来，至于其他东西，只能用户自己来实现了。
fabricjs则相反，fabric是一个重交互、轻渲染的库，其基于canvas2D实现，它本身自带了很多交互功能，比如框选，拖拽，zoom画布等，如果要开发一个2D编辑器项目，使用fabric将是最快的，很多编辑器相关的逻辑都不用自己实现，只需要专注于业务逻辑就可以了。但是显然，canvas2D的性能比webGL要差太多了，一旦节点数来到了数千，canvas2D将会被webGL远远甩在身后。
2.2 两个库实现自定义节点的区别
pixijs有一套自己的类来实现基础节点，比如Graphics用来实现一些几何图形，Sprite用来实现图片绘制，如果要自定义节点，可以通过继承这些类来实现。
fabric的自定义节点，则是通过ctx(CanvasRenderingContext2D)来实现的，保留了原生的canvas2D的味道。
2.3 开发一个2D编辑器，如何选择这两个库？
如果节点数量较少，使用fabric完全能hold住，它自带框选、成组、解组、拖拽、画布数据的导入导出等，开箱即用，适合快速搭建起一个编辑器。
如果要面对的是数千个节点的渲染，甚至上万个，那么fabric就顶不住了，巨大的渲染压力会让FPS急剧下降，画面变成PPT。这个时候就可以考虑pixijs了，webGL渲染带来的巨大提升，完全可以顶住渲染压力，不过，所有交互都要自己实现，这是一项很大的工程。
3. 本文的目的
既然fabric和pixi都有各自的优缺点，那么，可不可以取其精华去其糟粕，将两者结合一下，达到一个完美体呢？这就是本文的目的了，本文想用pixijs来复刻一个fabric，这样的话，这个fabric既有极快的渲染速度，又有开箱即用的框选、拖拽等功能，能够让用户快速开发出一个2D编辑器，岂不美哉！
