AntV 教你 2D Canvas 渲染优化

简介

HTML 上的图形渲染主要有两种方案 SVG 和 Canvas,前者更易于使用,而后者潜力更大,本文主要关注如何使用 Canvas 绘制出更多的图形,提供更加流畅的交互。本文的内容有:

  • 渲染机制
  • 性能瓶颈
  • 绘制更多的图形
  • 让交互更流畅
  • webGL 实现 2D 渲染

渲染机制

我们以简单的一个圆为示例,来对比 SVG 和 Canvas 的渲染:<br />
image.png
image.png
  • SVG 同其他的 HTML 标签一样,每个图形对应一个标签,图形的绘制同 HTML 标签一致
<svg>
<circle cx="100" cy="50" r="40" stroke="black" stroke-width="2" fill="red"/>
</svg>
  • 而 Canvas 本质上是一个图片,无论有多少个图形只有一个标签,需要使用 javascript 来绘制图形
<canvas></canvas>
<script>
  var ctx=c.getContext("2d");
    ctx.strokeStyle = 'black';
    ctx.fillStyle = 'red'
    ctx.lineWidth = 2;
  ctx.beginPath();
  ctx.arc(100,50,40,0,2 * Math.PI);
  ctx.stroke();
</script>

PS:你可以把 SVG 的理解成制作完一个个的图形放到页面上,而 Canvas 则是使用画笔一个个的绘制图形。<br />这篇文章并不是对比 SVG 和 Canvas 差异的文章,两者的差别 w3cshool 的描述非常准确。

如何拾取图形

circle-hit.gif
circle-hit.gif

<br />由于 SVG 的图形是一个个的 HTML 标签,所以 SVG 的图形天然支持浏览器的所有事件。而 Canvas 是一张画布,使用一支笔将图形绘制到画布上后,这些图形就成为了画布的一部分,每个图形都无法独立的对浏览器的事件进行相应。有什么方式判断指定点所在的图形呢?主要有两种方案:

  1. 浏览器提供了 isPointInPath 和 isPointInStroke 两个方法判定点是否在图形内,点是否在图形的边上。
  2. 缓存所有图形的属性,使用数学方法来判断指定点所在的图形。

我们依然以一个圆为示例,来看这两种方式:

浏览器的方法

使用浏览器的方法需要重新绘制一遍图形:

 ctx.beginPath();
 ctx.arc(100,50,40,0,2 * Math.PI);
 const inPath = ctx.isPointInPath(100, 100);
 const inStroke = ctx.isPointInStroke(100, 100);
  • 这是一种使用简单,同时所有图形都适用的方式,但是成本巨大,例如:鼠标每在画布上移动一次,都会导致所有的图形绘制一遍。
  • 建议图形个数小于 500 个时使用这个方案。

数学拾取

需要对每种图形提供判断是否在图形内部和图形边上的方法:

function isInCircle(point, x, y, r) {
    return distance(point.x, point.y, x, y) <= r;
}

function isInCircleStroke(point, x, y, r, lineWidth) {
  const d = distance(point.x, point.y, x, y);
    return d <= r + lineWidth / 2 && d >= r - lineWidth / 2;
}
const point = {x: 100, y: 100};
const inPath = isInCircle(point, 100, 50, 40);
const inStroke = isInCircle(point, 100, 50, 40, 2);
  • 性能好:从性能上来说数学拾取的性能比使用浏览器的方法要快 20 倍左右
  • 实现复杂:从实现上来说需要实现所有几何图形的数学计算,更多的数学计算参考 2D 图形计算

PS:两者的性能测试对比

浏览器 API 数学计算
1 111.02999997092411 4.779999959282577
2 110.53000000538304 5.694999999832362
3 117.55500000435859 7.979999994859099
4 126.2599999899976 5.354999972041696
5 110.8949999907054 4.725000006146729
6 121.6549999662675 6.2049999833106995
7 121.18500005453825 4.529999976512045
8 116.78500002017245 8.094999997410923
9 124.06000000191852 8.925000031013042
10 124.42499998724088 4.849999968428165
平均值 118.43799999915063 6.113999988883734

更多更快的拾取方案可以参考 2D 图形拾取方案

图形的更新

对于 SVG 的图形来说,直接修改对应标签的属性即可,有浏览器控制刷新图形。但是对于 Canvas 来说需要清除整个画布,重新绘制所有的图形,也就是说 Canvas 画布上有 10W 个图形,仅仅更新一个图形时,其他 99999 个图形也需要重新绘制。

function drawAll() { 
    // 绘制所有图形
}
function repaint() {
    ctx.clearRect(0, 0, width, height);
  drawAll();
}

性能瓶颈

从上面的渲染机制我们可以自然的推导出 Canvas 的图形渲染的性能瓶颈主要在三方面:

  • 同一时间绘制过多的图形,会阻塞浏览器的进程,导致页面不能响应
  • 鼠标在画布上移动时,如果不能及时捕捉鼠标,会导致卡顿
  • 图形更新时,重绘的时间过长,则帧率非常低

渲染的成本

我们以绘制 1W 个圆作为示例,来看一下单次绘制的成本:
image.png
image.png

需要 51 ms,假如我们要绘制 10W 个点,则需要 510ms

拾取的成本

前面我们测试过图形拾取和数学拾取的差异,1W 个圆的拾取需要 11ms左右,如果再加上图形刷新的响应,可以预期帧率会非常低。

更新的成本

我们以鼠标在画布上移动,移入一个圆这个圆变颜色,我们来看一下画布整体刷新时的效果:<br />
circle-hit1.gif
circle-hit1.gif
  • 可以看到明显的延迟,鼠标移动开一段距离后,点才响应
  • 鼠标移动过的路径,大部分圆没有响应

如果我们对圆进行动画看一下帧率:<br />
circle-hit2.gif
circle-hit2.gif

<br />可以看到动画的帧率在 8 帧左右

绘制更多的图形

首次渲染时的优化

当一次渲染的图形过多时,将一次渲染分成多次渲染,每次渲染时间增加几毫秒的间隔,这时候就不会卡顿:
image.png
image.png

<br />这种方案虽然会增加总的渲染时长,但是可以降低页面的卡顿感,对所有图形进行整体更新时也可以使用这个方案,但是进行交互时这种方案会带来一定的延迟。


draw2.gif
draw2.gif
  • 这是一个 10W 个点渲染(局部 画布 1000 * 1000,这里仅显示了500* 500 的范围)的效果,可以保证近乎 60帧的效果
  • 分段渲染的核心在于中间空白的间隔要足够小,这里面有很多的算法,就不在这里展开
  • 分段渲染时数据更新时怎么处理,可以参考 react fiber 的实现。

频繁渲染的优化

鼠标在画布上移动时,不断的导致重绘,我们只要能够保证 60 帧的重绘频率即可,所以重绘的间隔不能小于 16ms,我们可以将持续渲染的同步机制,改成每 16 ms 渲染的异步延迟渲染机制,这样可以大大降低重绘的频率。

image.png
image.png
<br />异步渲染依然有很多需要思考的地方,可以参考延迟渲染实现

更新的优化

我们可以实现图形的局部刷新,在局部刷新时仅清空图形所在的包围盒,所有与这个包围盒相交的图形全部刷新,这时候我们来看上面的两个示例:当鼠标在画布上移动时,这就流畅多了,基本上没有延迟

circle-hit4.gif
circle-hit4.gif
同样的动画,可以看到支持了局部刷新后可以直接到达 60 帧<br />
circle-hit3.gif
circle-hit3.gif
局部刷新的具体实现比这复杂的多,后面我会写一篇更详细的关于局部刷新的文章,这里可以参考 局部刷新文档

拾取的优化

拾取的优化我们在上面已经进行了简单的说明,数学拾取的性能远远超过使用浏览器的方法来拾取,更多的拾取方案参考:2D 图形拾取方案

webGL 实现 2D 渲染

渲染性能的提升

由于 webGL 的渲染是在 GPU 中进行,可以显著的提升渲染效率,可以看下面的示例:

draw3.gif
draw3.gif
  • 这是一个 80 * 80 * 80 = 512000 个点的示例

一些限制

  • 由于 webGL 的渲染时基于光栅(点),所以绘制线时本质上是通过一个个的点来绘制,逐点计算贝塞尔等曲线不现实,因此绘制的这些曲线不够平滑。
  • 绘制图形时尽量不要直接在 cpu 中计算各个图形的几何模型,而使用 shader 对图形进行计算和渲染,否则性能反而会下降
  • 文本的渲染非常复杂,也不会带来性能的提升

总结

这些优化大部分已经在 2D 绘图引擎 G上实现 ,2D 图形的渲染优化主要在异步渲染、拾取加速和局部渲染三个方面,但是每个方面都非常复杂,都可以独立成章,本文仅仅是从思路上进行讲解,更多更细的分析都会在后面提供独立的章节进行讲解,敬请期待!

AntV 官网:https://antv.vision/
2D 绘图引擎 G:https://github.com/antvis/g

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,658评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,482评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,213评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,395评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,487评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,523评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,525评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,300评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,753评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,048评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,223评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,905评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,541评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,168评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,417评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,094评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,088评论 2 352

推荐阅读更多精彩内容