canvas 3D渲染好双缓存文件画板

lxf2023-04-05 09:18:01

环境

文中已经参与「 . 」

关键在最近的立减突击过程中,运用了很多的特效。 但是有一个 锁匙破裂的影片特别卡, 一开始针对问题的概念是否页面中的序列帧动漫过多,造成canvas 消耗了 很多运行内存,由于播放这个序列帧动画情况下, 检测反映 安卓机 卡像ppt。可是iPhone却没事儿。

基本原理

我们首先看看 序列帧动画渲染的基本原理

  1. 第一步是把好几张照片转为 一张雪碧图 这儿就已经确认了 动画帧率
  1. 随后用 canvas 去3D渲染 每一帧

大伙儿看看这张图片:

canvas 3D渲染好双缓存文件画板

表明 其实也就是 大家canvas 的器皿, 而上边的 1-6 本身就是一张图, 因此序列帧动画 基本原理 便是 将1-6 这张图片 根据canvas drawImage api 每一帧 开展 提取,然后再进行3D渲染。

表面上看是没毛病, 很简单的逻辑3D渲染,可是再次绘制的全过程,实际上就是一个持续刷涂料-重绘的一个过程。但在屏幕上进行这一系列操作是必须一定时间的,并且屏幕上图型越复杂,所花费时间就越久,大家很明显的刷涂料-重绘实际操作,在使用中就会使就可能会感到显示器的闪动。 这便 为什么 在 锁匙崩裂那多张动漫卡屏。

canvas 3D渲染好双缓存文件画板

为了能认证我猜测, 我们将素材内容里的总体照片应用2x 图 去3D渲染, 在难题型号表现得卡屏大部分都是没了,可是 随着产生的一个问题便是图形的品质 就并不是很高。 这类针对开发设计来讲, 便是要构思让步,说图片太大。但这种针对客户体验而言,就不好。 于是就有了现阶段调查的预渲染 canvas , 实际上 便是在3D渲染以前 把这些 canvas 3D渲染好

双缓存文件画板

如今我们有一幅图必须放到Canvas中,应用drawImage()方式,有三种书写:

// 将image放进总体目标canvas指定地点
void ctx.drawImage(image, dx, dy); 

// 将image放进总体目标canvas指定地点,特定宽高比3D渲染
void ctx.drawImage(image, dx, dy, dWidth, dHeight);

// 将image裁切以后放进总体目标canvas指定地点,特定宽高比3D渲染
void ctx.drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);

第一种方式只是将照片原状放进Canvas中,第二种方式特定宽越高越代表着变大或是缩小图片之后再装进去,第三种是把图片裁剪之后再变大或是变小放进canvas中,这三种书写操复杂性作先后提升,特性花销也会跟着扩大。

而如果采用离屏3D渲染(即我们说的双缓存文件画板),我们能事先把图片裁剪成自己想要的规格,再将该具体内容保存,制作时直接应用第一种书写直接把照片放进Canvas中。

// 在距离屏 canvas 上制作var offscreencanvas = document.createElement('canvas');// 宽高比取值为想要的图片规格

offscreencanvas.width = dWidth;

offscreencanvas.height = dHeight;// 裁切

offscreencanvas.getContext('2d').drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);// 在主视图canvas中制作

viewcontext.drawImage(canvas, x, y);

双缓存文件画板技术性的核心是系统软件必须在内存中开拓一块与当前界面等各大的“逻辑性显示屏“。我们自己的绘图和动漫实际操作都要先应用于这方面”逻辑性显示屏“中,当一个实际操作在这片”逻辑性显示屏“上完毕之后,然后把一整块”逻辑性显示屏“推广到自己的屏上。

检测

我们首先看看未使用预渲染的 canvas 3x 图

canvas 3D渲染好双缓存文件画板

非常明显在崩裂的那几幁动漫,会卡屏, 仿佛就是卡住 一样。

采用了 预渲染以后我们看看 播放视频

canvas 3D渲染好双缓存文件画板

其背后的 基本原理 其实不是很难 看看这张图片:

canvas 3D渲染好双缓存文件画板

大家提前准备全部序列帧在总体目标canvas 的激光切割, 在这种全过程下,我们都是没法见到全部图型在屏幕上重绘全过程,进而克服了闪动难题。就像看动画一样,无需双缓存技术,便是画一帧看一帧,一定会卡屏。而使用了双缓存技术,会提前把每一帧画完,持续滚动呈现出来。这儿你们可以联想起 react 双缓存文件 fiber 树哦, 就能明白了。

存在的不足

预渲染canvas 存在的不足有下边2个

  1. 第一个是 在 ios 端 对canvas 的运行内存 受限制,假如序列帧的影片太多, 造成canvas 拿不了前后文
  2. 第二个就是 建立canvas 的js 实施时间 比较长, 在 安卓系统低端机 主要表现十分明显
  3. 有关问题改善对策 下一篇文章前去讲,留些伏笔, 可关注一波

未来发展趋势

Webgl 3D渲染

这不一定是一种比较好的计划方案,但对于不依靠 webgl 水平是一种提升方式, 假如后边还是对于序列帧动漫进行提升, 便是 根据webgl 去3D渲染每一帧的照片 ,这儿可以参考一下pixi 3D渲染精灵图, 或是标准图集

pixijs.huashengweilai.com/guide/start…

针对雪碧图的 照片存储, 假如高效率的3D渲染 。。。 我觉全是后边能够改善的方位

资源预加载计划方案

针对网络资源超出几M 的照片计划方案, 假如不加loading页, 我们应该怎么让消费者无感知,感受我们的游戏。 这都是大家可以选择提升的。