前些时候看到csdn上一篇文章介绍flashplayer的渲染效能是html 5的数倍文章，回想起几年来对adobe的flashplayer研究，想从理论上探究一下为什么会有这样的结果，同时也解释一下针对传统硬件加速（非gpu方案）为什么adobe的flashplayer会被批评的原因； 
早些年在一家ic设计公司为一个低端平台（具有硬件3d加速）作官方的flashplayer的硬件加速，几个月下来，硬件渲染引擎做好了，但最后的结果非常出人意料 ----- 改用硬件加速后的效能居然比软件渲染的要差；为了解释其中的原因，我们还是先从adobe的flashplayer软件渲染算法原理上入手； 
事实上，flashplayer的2d渲染引擎使用的是最为常见的扫描线算法（scanline算法），及简单的讲，是以虚拟显示设备（对于考虑抗锯齿的情况下，虚拟显示设备大于实际显示设备，如4 x 4抗锯齿，虚拟显示设备的纵向是实际显示设备的4倍）每条扫描线计算和矢量图形的各边（edge）的交点，并根据不同的填充法则填充两个交点间的水平线；这样随着扫描线自上而下逐条计算完成后，在虚拟显示设备中即完成了一幅完整图形的构成，然后，再根据超采样算法，将虚拟显示设备上的图形输出到实际显示设备上，这样，在实际显示设备上即得到一幅完美的无锯齿的图形；以一定的速率重复以上动作，及可以得到连续的动画；flashplayer通过解析流式的swf文件，并按照指定的速度更新画面完成动画的播放，因此，我们已经有些简单的结论： 
l  矢量运算是一个工程浩大的计算；这也解释了为什么flashplayer在多数平台上存在的效能问题；非常遗憾的是，当前实时2d矢量图形播放软件似乎只有flashplayer，所以这个黑锅是没办法了； 
l  为什么高画质的显示效能要较低画质的差很多呢；因为在高画质下，flashplayer是使用的4 x 4的超采样抗锯齿，及表示通过扫描线计算交点的计算量是低画质的4倍； 
（关于2d矢量图形显示，参考我之前的资源：http://download.csdn.net/source/5773340） 
在实际的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），我们很快发现了两处很有意思的说明： 
l  flashplayer仅支持2阶的贝塞尔曲线（quadratic bezier），而不支持类似postscript和openvg等传统2d矢量引擎中使用的3阶贝塞尔曲线（cubic bezier）；
相对2阶beizer曲线，3阶贝塞尔曲线单独一条在计算交点是增加的计算量似乎并不大：多了几次乘法运算；但在多数cpu体系中乘除法运算所消耗的时间会大于加减法，尤其在非常大的运算量下，其累积的差别就更大了； 
l  在adobe的官方文件中明确注明flashplayer不支持点划线（dash）
为什么不支持dash呢？事实上在矢量图形显示中，除了曲线和扫描线交点的计算外，最困难的是计算曲线的长度，dash的显示必须依赖事先的曲线长度的计算；在实现gingkovg时，不包含dash功能的曲线显示其显示效能是使用dash的4倍； 
l  仅此而已吗？并不是，不过即使以上的约束，其显示效能已经“被提升”了数倍。在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）