[转][心得] 关于BitmapData.draw()效率的一点发现

[url]http://bbs.9ria.com/viewthread.php?tid=46295&extra=page%3D1%26amp;orderby%3Ddateline%26amp;filter%3Ddigest[/url]


　　SP位图引擎制作中，目前刚写完MC逐帧转连续BitmapData，正着手于MC的结构分析生成BitmapData的关联数据。但是这里就碰到一个不得不面对的问题。就是纯位图引擎一般为了提高效率都普遍使用BitmapData.copyPixels()方法来绘制每一帧的图像。但是copyPixels并不带Matrix参数，也就是说如果要把于一个BitmapData缩放和旋转copyPixels就无能为力了。普通的做法是把一个BitmapData穷举出所有角度比如0到360度生成一个图像序列，但是结合缩放的话就没这么简单了，特别是即便能够穷举出序列占用的内存也会是原先的几十几百倍。

　　虽然现在还没做到这一步，但是总归是要面对的。本来是打算借由Alcamy的高速数据处理能力来解决旋转的图像数据变换问题。但是今天一个一直存在的疑问驱使我简单的做了个测试，那就是BitmapData.draw()虽然效率比不上copyPixels但是他真的就是那么差么？以往我们做的效率比较都是draw的一个实际容器对象(比如MovieClip)，很少会去拿BitmapData做参数。今天经过简单的测试发现，如果用BitmapData做参数即便加上Matrix参数带旋转和缩放的话也比直接draw容器要快70%，比copyPixels带透明绘制慢30%。

　　以一个150*150尺寸的图像做测试源，5000次循环：

１、copyPixels(bitmapData,rect,point,null,null,false) 消耗 120 ms; // 平均每次　0.024 ms

２、copyPixels(bitmapData,rect,point,null,null,true) 消耗 330 ms; // 平均每次　0.066 ms

３、draw(bitmapData,matrix) 消耗 460 ms; // 平均每次　0.092 ms

４、draw(MovieClip) 消耗　1700 ms; // 平均每次　0.34 ms


　　可见如果考虑到图形旋转缩放的话直接使用draw(bitmapData,matrix)其实并没太多的额外消耗，最重要的是如果自己写旋转变换然后copyPixels未必能比它快。那么剩下的就是在引擎中如何正确判断该用1 2 3哪种方式来进行绘制了。

　　今天的发现一来改观了我对draw效率的看法，它的效率并不低实际要看怎么使用。２来也基本解决了位图引擎的缩放和旋转问题，节省了这部分自行开发的时间。