GDI绘制界面注意的几点

  GDI绘图和openGL等其他绘图方式都是将图片绘制在指定屏幕的像素点上，不同的是GDI没有也不需要3D硬件加速等功能！所以GDI理论上的速度只和硬件有关。GDI刷子等概念并没有显卡硬件加速功能，所以要使用双缓冲区的概念。GDI+在这方面有所改进但也不太乐观。所谓双缓冲简单的说就是把图片绘制完成处理后形成一张定格的图片后在输出到显卡。

    当使用GDI绘制图片时（GDI本来就是绘制简单图片使用的）理论上只是期待最后形成的图片，其间处理的过程所用的时间用户的能够忍受的。当使用GDI绘制界面就完全不同了，用户是不能忍受任何界面的延时。

    所以GDI绘制界面要尽量使用绘制好的图片，不要使用刷子等工具现画。这不是水平高低的问题，前面说过GDI是没有硬件加速功能使用刷子等绘图工具会占用cpu使用量。界面又是用户反复操作，当操作速度过快时就会大量占用cpu使机器性能下降。

    是不是使用双缓冲，贴图片这样就ok了呢，答案是否定的。win32编程并不很好的支持gdi绘图的方式绘制界面。无论是mfc,还是atl或wtl，他们支持的都是以窗口为单位绘制界面的方式。在实践应用中发现窗口方式本身并不是效率很高的方式。消息机制的不确定性决定了窗口方式会出现大量的耦合因素。简单的说不要让任何的消息处理卡驻消息循环泵！否则在高效的界面都会看起来奇慢比。这里的矛盾是消息机制本身就要求了消息处理方式是分散式的，当分散的甚至是离散的或有相当隐蔽性消息处理方式点滴的速度延时累计起来就直接反映在了你的界面延时上了。界面是一个整体这和消息的分散处理方式是很矛盾的，分散的东西给人的印象就是可以越来越多，又不相互影响，但延时的时间却统一的反映在了一个界面上。

    这里又说道了界面设计的问题，最理想的方式是所有界面功能都立即返回近似于异步处理。但你想想用户点击了一个按钮立即返回了，而他的功能还在后面处理没有结果，用户是什么反映？软件有问题吗我点击了为什么没有反映？但这个时候锁住界面吗？当然不行。没个几秒钟延迟都要锁住界面用户还不恼怒？

    说的有点跑题了，我不会在这里提供一个万能的解决方案。软件大小不一样解决的方式也多种多样。这已经远远超出了一个界面的问题。变成1+1！=2的软件工程问题，软件还是没有银弹的。那么窗口既然会带来这么多问题在使用gdi绘制界面的时候就要格外小心使用窗口。尽量不要在同一窗口绘制所有功能元素比如一大堆的按钮，tab页，子窗口等等。祝你绘制界面愉快！