浏览器的渲染技术 v.s. CG渲染器的渲染技术
看了两篇文章: 浏览器的渲染原理简介, How browsers work(译文), 想到了一些东西, 对比两者, 或许有些东西能想得更明白些.
以下CG Rendering 简称R, Browser简称B.
共同点:
-两者都有文本描述文件
R: rib, ass, ....
B: html
-两者的任务都是渲染
R:从文本描述文件得到一张图片(图片里包含了模型, 材质, 灯光,....)
B:从文本描述文件得到一个网页, 包含文字, 图片(位置, 布局, 放缩), 视频, 音频, flash,....
不同点:
- 最根本的不同是两者的渲染方式. 比如两者如何渲染带动画的元素(R渲染带动画的模型, B渲染带动画的文字或图片). R和B对动画的解决方法完全不同, 这个最根本的分歧导致两者发展出各自的技术.
对于R来说, 要渲染一个24fps的动画, 就要生成每一帧的图片, 然后把这些图片按顺序播放, 使得人们看到一段动画. 这是电影胶片的思路. 无论游戏(OpenGL/Dirext3D)还是动画/VFX都是这么做的.
比如, 场景描述文件要渲染24帧(f0~f23), 场景里包含2个元素A0, A1(A0做平移, A1是静止的). 那么渲染第0帧f0的时候要计算A0和A1的数据, 渲染f1的时候同样要重新计算A0和A1的数据, 只不过A0的位置不同而已(所以才产生了动画), f2~f23也是类似, 即每一帧都要重新计算A0和A1的数据.
对于B来说, 它基于操作系统的window manager(比如XWindow)来显示元素, 而window manager不借助于opengl/d3d来显示(渲染)一个元素.
比如, B要渲染2个元素A0, A1(A0做平移, A1是静止的). 那么, 初始时A0和A1都被渲染出来. 之后把A0的像素平移到下一个位置, 而A1的大部分(或者说没有被A0影响到的)像素并不改变. 所以A1的大部分(或者说没有被A0影响到的)像素并没有被重新计算!
(是否可以说B里的A0和A1的渲染是异步的? )
- R的优势在于, R的渲染方式能hold住更复杂的场景(你看看那些游戏和电影场景).
- B的优势在于, 如果你要滚动页面, 页面上的所有静止元素(比如静态文字, 静态图片)都不需要重新渲染, window manager只需做平移就可以了, 这个计算量很小.
- shader
我是站在R的角度来说的, 所以R里的shader的概念不必多说. 那么, B里有没有什么类似的东西对应于R里的shader呢?
先想想R里的shader到底是什么, 是做什么的.
我想, 最简单的情况, A0和A1, A0是红色,A1是蓝色. A0和A1需要两个不同的shader.
我猜, 起初, 人们可能把红色和蓝色写死在shader里, 于是, shader0是一段代码, 赋给了A0并渲染出红色; shader1是另一段代码, 赋给了A1并渲染出蓝色.
后来, shader写的多了, 人们为了方便, 把不变的代码提出来形成shader函数体, 而把变化的代码(红色值和蓝色值)提出来作为shader的参数.
那么, 我想B里的这些代码就类似与R里的shader:
<font color="#FF0000">我是红色字体</font> <font color="#0000FF">我是蓝色字体</font>
- CG行业里的shader一直在发展, 比B里的"shader"要复杂得多. 如果把R里的shader的概念和技术引入到B里, 会怎样?
(未完, 待续)
References:
[1] 浏览器的渲染原理简介
[2] How browsers work, (译文)
