先说明一下，fanvas是笔者在企鹅公司开发的，即将开源的flash转canvas工具。

脏区重绘(dirty rectangle)并不是一门新鲜的技术了，这在最早2D游戏诞生的时候就已经存在。

复杂的术语或概念就不多说，简单说，脏区重绘就是每一帧绘制图形界面的时候，只重新绘制有变化的区域，而不是全屏刷新。很明显，这肯定能带来性能的提升。

举个例子，看下边两个图：

假设这里是动画的连续2帧，那么从第一帧到第二帧，其实变化的只有蝴蝶的区域。那么所谓的脏区就是两个图片的红色框之和，要把上一帧的蝴蝶擦掉，然后把新区域的蝴蝶位置也擦掉，接着才能绘制新的背景和蝴蝶。这相比整屏重绘，重绘的面积小了几十倍，由于canvas 2d使用的是CPU处理，那么相应地，CPU处理的像素个数就少了很多倍，顺理成章，动画的效率就会提高。

看起来非常简单，大概来说，只需要2步：

1、找出这一帧变化的矩形区域；

2、利用canvas的api实现脏区重绘。

但是，问题来了，怎么计算变化区域呢？canvas又是否提供了现成的接口呢？我们拿上述蝴蝶的例子，逐步来看看。

首先，我们看关于脏区的计算。

如果动画非常简单，没有使用“显示列表”，所有图案都是一层绘制的，那么“也许”绘制者，也就是开发者了，可能会知道蝴蝶的位置，然后手工指定重绘的区域。呃。。。等等，好像有点什么问题，不可能每次都手工指定重绘的区域！！！

再看看Fanvas里的情况，Fanvas采用了显示列表，把图案拆分为多个元件，元件和元件之间以“显示列表”的形式组织起来，这参考了Flash的技术。这里，蝴蝶被封装为一个Shape，蝴蝶在画面飞舞，抽象为Shape在父元件中移动、旋转。最初，在Shape中绘制蝴蝶的时候，可能占据的矩形区域是(x:0,y:0,width:100,height:50)，这里参考的是Shape内部的坐标系（还没放到舞台上）。然后，蝴蝶被添加到舞台上时，需要位移和旋转，例如做了(x:400,y:100)的位移，和旋转了60度。这时候如何计算新的矩形呢？

这个过程其实就是局部坐标系映射到全局坐标系的问题，涉及到矩阵计算，可以参考我之前写的文章，这里就不多说了。 。另外，提一下，这里其实还有一个难点，初始绘制时(x:0,y:0,width:100,height:50)，这个矩形是如何计算得到的呢？如果绘制的是一个图片，那当然好计算；如果是一系列的矢量线条，这个就略麻烦了，不过这个不在这里讨论了，因为Fanvas是Flash导出Canvas动画，在导出的时候Flash自带了这个矩阵信息。

上述的计算都在一个前提情况下：我们已知蝴蝶是唯一一个变化的元件，但在实际动画过程中，如何自动识别变化的内容呢？

要从动画的原理说起，动画过程无非分为4种操作：

1. 新建一个元件（例如蝴蝶），添加到舞台上；

2. 移动、旋转、放缩原有的元件；

3. 删除已有的元件；

4. 修改元件的遮罩关系，这点有点特殊，如果对flash动画不熟悉的同学可能不大理解，不过不重要，我们知道有这回事就可以了，不影响文章的继续阅读。

那么，在Fanvas中，我们就需要对上述4种情况分别处理。

1. 新建：只有1个脏矩形，就是这个元件本身；

2. 移动/旋转/放缩：元件上一帧的矩形区域是脏区，新一帧的矩形区域也是脏区；

3. 删除：跟新建情况一样；

4. 遮罩变化：跟2一样。

理清楚这些细节之后，如何实现就比较好办了，无非就是每一帧绘制前把脏区列表情况，然后计算出所有脏区矩形，再开始绘制。

接着，我们再来看第二步，canvas如何具体操作，是否有脏区重绘接口？

其实，canvas并没有真正的脏区重绘接口，不过有一个clip，这个一般用于实现遮罩，不过也可以取巧的用来实现脏区重绘。经笔者测试，简单使用clip虽然性能优化不是太明显，但还是有20%的提升的。再复杂一些，当然大家可以自行根据脏区列表，重写每个元件的绘制方法，自行实现脏区重绘，不过笔者估计啊，js写这么多逻辑，最终还是吃力不讨好。

我们来看看代码：

(rect =rect = dirtyRectList[i]; ctx.rect(rect.x-1, rect.y-1, rect.width+2, rect.height+2);} ctx.clip();

至此，Fanvas脏区重绘的秘密就彻底曝光了。。。

最后来看看实际的效果（第一张是没有使用脏区重绘，第二张使用脏区重绘）：

当然，这并不是每个动画都有效果，因为一些动画本来就大范围变化，所以Fanvas针对这些情况也做了兼容处理，如果发现脏区太多或者面积太大，就继续使用原来的全屏重绘。