前些时候看到一篇文章介绍FlashPlayer的渲染效能是HTML 5的数倍文章,回想起几年来对Adobe的FlashPlayer研究,想从理论上探究一下为什么会有这样的结果,同时也解释一下针对传统硬件加速(非GPU方案)为什么Adobe的FlashPlayer会被批评的原因;
早些年在一家IC设计公司为一个低端平台(具有硬件3D加速)作官方的FlashPlayer的硬件加速,几个月下来,硬件渲染引擎做好了,但最后的结果非常出人意料 ----- 改用硬件加速后的效能居然比软件渲染的要差;为了解释其中的原因,我们还是先从Adobe的FlashPlayer软件渲染算法原理上入手;
事实上,FlashPlayer的2D渲染引擎使用的是最为常见的扫描线算法(Scanline算法),及简单的讲,是以虚拟显示设备(对于考虑抗锯齿的情况下,虚拟显示设备大于实际显示设备,如4 x 4抗锯齿,虚拟显示设备的纵向是实际显示设备的4倍)每条扫描线计算和矢量图形的各边(Edge)的交点,并根据不同的填充法则填充两个交点间的水平线;这样随着扫描线自上而下逐条计算完成后,在虚拟显示设备中即完成了一幅完整图形的构成,然后,再根据超采样算法,将虚拟显示设备上的图形输出到实际显示设备上,这样,在实际显示设备上即得到一幅完美的无锯齿的图形;以一定的速率重复以上动作,及可以得到连续的动画;FlashPlayer通过解析流式的swf文件,并按照指定的速度更新画面完成动画的播放,因此,我们已经有些简单的结论:
1)矢量运算是一个工程浩大的计算;这也解释了为什么FlashPlayer在多数平台上存在的效能问题;非常遗憾的是,当前实时2D矢量图形播放软件似乎只有FlashPlayer,所以这个黑锅是没办法了;
2)为什么高画质的显示效能要较低画质的差很多呢;因为在高画质下,FlashPlayer是使用的4 x 4的超采样抗锯齿,及表示通过扫描线计算交点的计算量是低画质的4倍;
(关于2D矢量图形显示,参考我之前的资源:http://download.csdn.net/source/577334)
在实际的2D矢量引擎中,问题往往更为复杂,在考虑Cap和Join后,实际即使是一根很简单的折线或Bezier曲线都是由很多的曲线构成的(如图折线的两个端点 ---- Cap):
这样可以理解为什么现在为止鲜有可以和Adobe FlashPlayer相抗衡的实时2D矢量显示程序了,这是不是有些矛盾:为什么Adobe的FlashPlayer会一枝独秀呢?以上只是关于2D矢量图形显示的原理性解释,其他2D矢量显示引擎,如OpenVG(gingkoVG)、agg等使用的是完全相同的原理,Adobe的FlashPlayer相对通用的2D矢量显示引擎一定有他自己特殊的定义,仔细阅读Adobe关于FlashPlayer的官方技术文件(swf_file_format_spec_v10),我们很快发现了两处很有意思的说明:
1)FlashPlayer仅支持2阶的贝塞尔曲线(Quadratic Bezier),而不支持类似PostScript和OpenVG等传统2D矢量引擎中使用的3阶贝塞尔曲线(Cubic Bezier);
相对2阶Beizer曲线,3阶贝塞尔曲线单独一条在计算交点是增加的计算量似乎并不大:多了几次乘法运算;但在多数CPU体系中乘除法运算所消耗的时间会大于加减法,尤其在非常大的运算量下,其累积的差别就更大了;
2)在Adobe的官方文件中明确注明FlashPlayer不支持点划线(Dash)
为什么不支持Dash呢?事实上在矢量图形显示中,除了曲线和扫描线交点的计算外,最困难的是计算曲线的长度,Dash的显示必须依赖事先的曲线长度的计算;在实现gingkoVG时,不包含Dash功能的曲线显示其显示效能是使用Dash的4倍;
仅此而已吗?并不是,不过即使以上的约束,其显示效能已经“被提升”了数倍。在Adobe的FlashPlayer中,针对渲染同时使用了其他的一些优化算法,当然这些优化算法作为通用优化技术在多数2D矢量引擎中也会被使用;(参考:http://download.csdn.net/source/1998019)
非常遗憾的是多数2D矢量引擎因为需要考虑通用性,都会支持3阶贝塞尔曲线和点划线,甚至是圆弧(OpenVG),这样从算法层面上我们不难理解为什么那些使用标准2D渲染引擎(如gnash使用了agg)的开源FlashPlayer无法和Adobe的FlashPlayer的执行效能相比较了----- 因为FlashPlayer的2D渲染引擎是针对Flash播放的实时性的需要量身定做的;当然,Adobe的FlashPlayer除了这些外,在程序的优化上有很多高明之处,这些不是我们这里需要讨论的;
事情似乎就此可以告一段落了,但随着对FlashPlayer的深入研究,我们发现了一些更深入的问题 ----- 及Adobe的FlashPlayer被广为批评的硬件加速效能差的原因;在不考虑针对特殊GPU的硬件加速,我们仅仅考虑标准硬件加速方式(OpenGL ES/OpenVG)来解释这个问题;Adobe的FlashPlayer在诞生时,那个时候还没有通用的2D矢量显示标准(如OpenVG),其针对软件渲染的2D矢量图形显示可谓是亮点,在经过十几年的发展和优化,Adobe的2D软件矢量渲染引擎可谓是已经发展到尽善尽美了,这也可以解释为什么自FlashPlayer 4到FlashPlayer 8其渲染引擎一直没有太大的变化,也可以解释为什么Adobe FlashPlayer软件渲染的效能甚至会好于使用低端硬件加速的效能了;但,成也萧何败也萧何,过于完美的标准和算法阻碍了使用标准硬件加速的可能(针对特殊GPU的硬件加速,因为其灵活性不在我们的考虑中),我们继续仔细研究Adobe的官方文件,我们注意到,关于填充法则FlashPlayer相对传统的2D矢量引擎有不同之处:传统的2D矢量引擎(如OpenVG/gingkoVG)有两种填充法则:奇偶填充法则(Even-odd fill rule)和非零填充法则(Non-zero fill rule),而Adobe的FlashPlayer又增加了边边填充法则(Edge-edge fill rule),及多数2D矢量引擎针对每个Shape/Object使用单一的着色方式(RColor),而在边边填充法则中,一条边根据左右不同可以分别拥有两种不同的着色方式(color1/color2),当然Adobe这样做的原因是增加了软件渲染的灵活性,如在两个Shape相交时对于相交部分允许使用不同的着色方式,如图:
遗憾的是这样在使用标准图形加速引擎时(OpenVG/OpenGL)会为我们带来困惑:即针对一个Shape我们可能会有不同的着色方式,这似乎是有悖于多数2D矢量引擎;尽管针对边边填充法则我们可以视作是两个不同奇偶填充法则,但考虑到针对每条边因此可能随时变化的填充法则,具有单一Color的Shape的重新确认并非那么容易,尤其对于由曲线构成的Shape。不过这个问题相对2D矢量图形渲染并不是很麻烦,但我们因此可以发现针对现在多数传统2D矢量引擎,Adobe FlashPlayer似乎并不“友善” ----- 程序员必须小心编写一个中间层解决这些问题,这并非是Adobe的错误:在FlashPlayer诞生时这些2D矢量显示标准(OpenVG)还没有出现; 只是非常可惜的是Adobe的FlashPlayer并非开源程序(Adobe FlashPlayer的AVM2已经开源),因此,我们必须耐心等待Adobe为我们去作这些,除非我们不准备使用官方的FlashPlayer;
(我们自己使用OpenVG的FlashPlayer)
(首发Blog,我将我在CSDN:http://blog.csdn.net/tomsoft上一篇Blog迁移到这里;希望新的家能有真正对技术感兴趣的童鞋一起参与进来)