Open ccforward opened 8 years ago
文章好,图也挺好的。
不过我觉得 生成这个元素的位图
这一部分不是很详细,可以稍微补充详细点。
所谓 生成这个元素的位图
其实是 纹理(texture)
,在 Chrome 中,存在有不同类型的层: RenderLayer(负责 DOM 子树),GraphicsLayer(负责 RenderLayer 的子树),其中 GraphicsLayer 层是作为纹理(texture)上传给 GPU 的。
这里的纹理指的是 GPU 的一个术语:可以把它想象成一个从主存储器(例如 RAM)移动到图像存储器(例如 GPU 中的 VRAM)的位图图像(bitmap image)。一旦它被移动到 GPU 中,你可以将它匹配成一个网格几何体(mesh geometry),在 Chrome 中使用纹理来从 GPU 上获得大块的页面内容。通过将纹理应用到一个非常简单的矩形网格就能很容易匹配不同的位置(position)和变形(transformation),这也就是 3D CSS 的工作原理。
而 transform 移动元素时就是移动这些生成的 GraphicsLayer 层从而避免了浏览器大量的reflow(relayout)而提升性能的。
那么一个元素什么时候会触发创建一个层?从目前来说,满足以下任意情况便会创建层:
@chokcoco
对于 纹理(texture)
确实没有深入的研究过。
非常感谢,补充的很详细。
嗯嗯 很好 学习了
怪不得有的文章提到给css加上一个并不移动的 3D transform 就能加速。
👍 终于比较详细的了解了所谓的 开启 GPU 加速 了
两张图解释CSS动画的性能
在手机上使用CSS动画时很多时候会感到卡顿,然后网上很多教程说开启GPU加速
transform: translate3d(0,0,0);
可解决,但是为什么开启GPU加速就能让动画顺滑呢?我们从浏览器内部去理解下
JS是单线程的,但是浏览器可以开启多个线程,渲染一个网页需要两个重要的线程来共同完成:
主线程的工作:
绘制线程的工作:
我们知道如果长时间的执行 JS 会阻塞主线程,页面就会出现各种的卡顿。
而绘制线程会尽量的去响应用户的交互,页面发生变化时,绘制线程会以每秒60帧(60fps是最适合人眼的交互,30fps以下的动画,让人感觉到明显的卡顿)的间隔不断重绘页面。
GPU 在如下方面很快:
但是在将位图加载到GPU内存中有点慢
关于两张图的正题来了
一个从
height: 100px
到height: 200px
的动画按照下面的流程图来执行各种操作图中有那么多的橙色方框,浏览器会做大量的计算,动画就会卡顿。
因为每一帧的变化浏览器都在进行布局、绘制、把新的位图交给 GPU 内存(这恰好是我们上面提到的GPU的短板)
虽然只改变元素高度但是很可能要同步改变他的子元素的大小,那浏览器就要重新计算布局,计算完后主线程再来重新生成该元素的位图。
使用 transform 属性的动画
流程图如下
很明显,这么少的橙色方框,动画肯定会流畅。
因为
transform
属性不会改变自己和他周围元素的布局,他会对元素的整体产生影响。因此,浏览器只需要一次生成这个元素的位图,然后动画开始时候交给 GPU 来处理他最擅长的位移、旋转、缩放等操作。这就解放了浏览器不再去做各种的布局、绘制等操作。
chrome中执行对比
把上面的demo代码在浏览器中执行下看下效果,demo地址: http://ccforward.github.io/demos/css/animation.html
transition: height 1s linear
transform: scale(1.0)
同样是改变大小的 scale 动画
参考信息:
http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/