这两天在论坛里看到有人在问WinCE6.0下绘图较慢的问题。现象很奇怪,同一个程序在WinCE5.0下运行得很好,但到某些WinCE6.0的平台上却很慢,而在另外一些6.0的平台上似乎又没有问题。看起来,应该跟硬件平台或者系统有关系。在我们的平台上也存在类似的问题,界面有点慢。这是为什么呢?又应该如何解决?是24位色导致系统变慢?使用DirectDraw能否有效的提高速度?为了寻找答案,今天利用TCPMP在我们的平台上做了一个详细的检测,希望能从中找到一些线索。
测试的方法如下,采用同一个MP4文件,分别在16位色和24位的系统上进行BenchMark,ZOOM都选定为100%,渲染方式分别为GDI、Direct、DDraw-RGB和DDraw-YUY2。
先看看16位色下的四组数据。
16位色GDI渲染时的报告结果:
Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1 Average Speed 268.84%
Video Frames 1933
Audio Samples 3504097
Amount of Data 11401 KB
Bench. Time 0:28.760
Bench. Frame Rate 67.21
Bench. Sample Rate 121835
Bench. Data Rate 3.2 Mbit/s
Original Time 1:17.319
Original Frame Rate 25.00
Original Sample Rate 44100
Original Data Rate 1.2 Mbit/s
URL \NAND\123.avi
Size 11675460
Platform PLATFORM_TYPE
OS Version 6.00
OEM Info PLATFORM_OEM
Clock speed 480 Mhz
Video output GDI 解码 800x480 16bits Lookup
Video zoom 320x240 -> 320x240
Audio output Wave Output 44100Hz 16Bits 2Ch.
,在24位色模式下,GDI依然是最慢的,Direct和DDraw-RGB还是不相上下,但比使用GDI高了很多,DDraw-YUY2依旧傲视群雄,几乎是GDI的2倍。
再看16位色和24位色,虽然同是使用GDI渲染,但24位色的系统显然慢了很多。而位色深度似乎对Direct和DDraw影响很小,几组值都相差无几。
最后再看看DDraw内部的差别,使用RGB和YUY2显然效果大不一样,几乎提高了20%。这可能主要是因为使用YUY2解码时不需要做颜色转换,从而省了很多时间。对于界面开发来说,我们大概可以使用Direct或者DDraw-RGB来提高绘制的效率。具体采用哪一种看具体情况,简单方便易实现是宗旨。
以上列举的这些应该可以说明一些问题,但不能以偏概全,最后的答案还得继续寻找。