GDI操作过程:往窗口的DC上以红绿蓝三种颜色分别画255根渐变的竖线。如图
显示结果:
设备兼容位图DDB:BitBlt use tickcount is 13
DIB位图(格式不兼容):StretchDIBits use tickcount is 184
rgb565 DIB位图: 16BPP StretchDIBits use tickcount is 12
RGB565 DIB位图: 16BPP BitBlt use tickcount is 13
直接写屏:FrameBuffer use tickcount is 9
结论:创建DDB位图与DIB位图,在贴图时的速度是一样的。唯一区别就是如果创建的DIB位图必须要与驱动里的位图格式一样,包括BIT_MASK的格式一样,也就是驱动里为RGB565的格式,应用里创建的位图也应该是RGB565的DIB位图,否则在BITBLT时驱动里会做一个RGB的转换,导致画图速度很慢,而创建DDB位图是不存在这种问题的,在速度上是不会慢的。
全部GDI操作的时间统计结果(只包括GDI操作,创建画笔,MOVETOEX,LINETO,SelectObject,BitBlt等,不包括位图创建,DC创建等):
BitBlt use tickcount is 443
StretchDIBits use tickcount is 610
16BPP StretchDIBits use tickcount is 438
16BPP BitBlt use tickcount is 439
FrameBuffer use tickcount is 116
结论:使用GDI时,前四种情况下的速度是一样的,与位图的格式无关,只是使用BitBlt时会因为位图格式不兼容造成很大性能损失。
但是如果使用直接写屏的操作可以把简单的GDI函数调用转换为纯粹的内存赋值操作,这种操作可以省掉很多时间。实际上可以用DIB位图来进行这种操作,直接针对DIB位图的内存数据写值来实现GDI的操作。
把16BPP的BitBlt修改为直接内存写值的操作,时间结果为:
BitBlt use tickcount is 442
StretchDIBits use tickcount is 611
16BPP StretchDIBits use tickcount is 441
16BPP BitBlt use tickcount is 106
FrameBuffer use tickcount is 104
由此可见,这种情况下与直接写屏的效率是一样的,对于频繁的GDI操作绘图,重写GDI的API调用可以节省不少的时间,前提就是使用与显示驱动兼容的DIB位图,然后直接对位图数据写值。