用VC实现双缓冲技术.docVIP

用VC实现双缓冲技术.txt不要放弃自己！ -------（妈妈曾经这样对我说，转身出门的一刹那，我泪流满面，却不想让任何人看见！） 看到这一句 小编也心有感触，想起当初离家前往几千里外的地方的时候，妈妈也说过类似的话，但是身为男儿，必须创出一片天，才能报答父母的养育之恩！！ 用vc 做的画图程序，当所画的图形大于屏幕时，当拖动滚动条时屏幕就会出现严重的闪烁情况，为了解决这一问题就得使用双缓冲来解决这一问题，程序产生严重的闪烁问题是因为画图过程中前后两次的画面反差很大造成的人的视觉的闪烁。因为在VC中每次在调用OnDraw时系统都是先用背景画刷将画布清除再执行画图命令，这样在你每次移动滚动条时每执行一次OnDraw就会有一个空白页，这样和你的最终结果图象之间有一个很大的反差，因而看起来闪烁，而且滚动条滚动越快闪烁越严重。你也可以将背景画刷设为NULL，这样可以解决闪烁问题，但是不能将先前的图象擦除，这样整个屏幕显得很乱。下面将利用双缓冲来解决这一问题的思路给大家作一下简单的介绍。 　　我先来解释一下在mfc里面很关键的设备环境描述符，也就是所谓的DC（device context）。 还是从历史来看吧，dos时代，我们如果要绘图，必须通过一系列系统函数来启动图形环境（用过turbo pascal或者turbo c的人该还有印象吧），这之间对各种硬件的初始化参数都不相同，非常的烦人，常常还要查阅硬件手册，那时的程序智能针对最流行的硬件来编写，对不流行的就没有办法了。windows操作系统为了屏蔽不同的硬件环境，让编程时候不考虑具体的硬件差别，采取了一系列办法，设备环境描述符就是这样产生的。简单的说，设备描述符抽象了不同的硬件环境为标准环境，用户编写时使用的是这个虚拟的标准环境，而不是真实的硬件，与真实硬件打交道的工作一般交给了系统和驱动程序完成（这同样解释了为什么我们需要经常更新驱动程序的问题）。使用在windows图形系统（gdi，而不包括direct x）上面，就体现在一系列的图形DC上面，我们如果要在gdi上面绘图，就必须先得到图形DC的句柄（handle），然后指定句柄的基础上进行图形操作。 再来回忆一下，我们怎么在sdk的环境下面绘图呢，我想这个大家都不太清楚吧，但是确实很基础。在windows的sdk环境下面，我们用传统的c编写程序，在需要的绘图地方（比如响应WM_PAINT消息的分支）这样做： hdc = GetDC( hwnd ); oldGdiObject = SelectObject( hdc,newGdiObject ); ...绘图操作... SelectObject( hdc,oldGdiObject ); DeleteObject( newGdiObject ); ReleaseDC( hdc); 或者是这样 BeginPaint( hwnd,ps );//PAINTSTRUCT ps -- ps is a paint struct ...绘图操作... EndPaint( hwnd ) 这就是大概的过程，我们看到了hdc（图形DC句柄）的应用，在绘图的部分，每一个绘图函数基本上也要用到这个句柄，最后我们还必须释放它，否则将严重影响性能。每次我们都必须调用GetDC这个api函数得到（不能用全局变量保存结果重复使用，我在后面解释）。这些是最最基本的windows图形操作的方式，相比dos时代简单了些，但是有些概念也难理解了些。vb里面的简单的point函数其实最后也是被转化为这样的方式来执行，系统帮助做了很多事情。 到了mfc里面，由于有了封装，所有的hdc被隐藏在对象中做为隐藏参数传递（就是DC类的this啦～～），所以我们的关键话题就转变为了怎样得到想要的DC类而已，这个过程其实大同小异的。在消息响应的过程中，WM_PAINT被转变为OnDraw()，OnPaint()一系列函数来响应，这些函数一般都有个参数CDC *pDC传入进来，因此在这些函数里面，我们就只需要直接画图就可以了，和以前sdk的方式一样。 但是WM_PAINT消息响应的频度太高了，比如最小化最大化，移动窗体，覆盖等等都引起重绘，经常的这样画图，很是消耗性能；在有些场合，比如随机作图的场合，每一次就改变，还导致了程序的无法实现。怎么解决后一种问题呢。 ms在msdn的例子里面交给我们document/view的经典解决办法，将图形的数据存储在document类里面，view类只是根据这些数据绘图。比如你要画个圆，只是将圆心和半径存在document里面，view类根据这个里面的数据在屏幕上面重新绘制。那么，我们只需要随机产生一次数据就可以了。 这样还是存在性能的问题，于是我们开始考虑另外的解决方法。我们知道，将内存