Win32汇编 图形操作 GDI原理.docVIP

Win32汇编 图形操作 GDI原理 世界上只有一种失败，那就是半途而废。~~天道酬勤。~~苦我心志，劳我筋骨。~~… Win32汇编--图形操作--GDI原理 Windows是基于图形界面的，所以在Win32编程中，图形操作是最常用的操作。GDI的意义在于将程序对图形界面的操作和硬件设备隔绝开来，在程序中可以将所有的图形设备都看成是虚拟设备，包括视频显示器和打印机等，然后通过GDI函数用同样的方法去操作它们，由Windows负责将函数调用转化成针对具体硬件的操作。只要一个设备提供了和Windows兼容的驱动程序，它就可以被看做是一个标准的设备。以前在DOS系统下写应用程序的时候，如果要进行图形操作，那么就要考虑到市场上每种显示卡的不同，否则在装配某种显卡的计算机上就可能无法正常运行，对汇编程序员来说，这真是一个恶梦。在Win32编程中，正是GDI函数让这个恶梦成为历史。 GDI函数全部包括在GDI32.DLL中，在编程的时候，注意要在源程序的开头加上相应的包含语句： include gdi32.inc includelib gdi32.lib 和GDI相关的内容真是太庞大了，只要查看一下gdi32.inc文件就可以发现，函数的总数达到了300多个，和GDI相关的数据结构也非常多，为了能了解GDI的原理和基本的使用方法： 归纳起来，GDI操作可以从3个方面去了解--When,Where和How When--指的是进行图形操作的时机，究竟什么时刻最适合程序进行图形操作呢?--GDI程序的结构 Where--指的是图形该往哪里画，既然Windows隔离了硬件图形设备，那么该把什么地方当做下笔的地方呢?--设备环境 How--了解了上面两个问题后，最后还要知道如何画，这就涉及如何使用大部分GDI函数的问题了。 一、GDI程序的结构 1、客户区的刷新 正如上面所说的，这里讨论的是When的问题，读者可能会问：为什么会有这个问题，如果要向窗口输出图形，程序想在什么时候输出那就是什么时候，难道这个时刻还有规定不成? 在DOS操作系统中编程的时候，程序把文字或图形输出到屏幕，在输出新的内容之前，这些内容总是保留在屏幕原处，这些内容会被意外覆盖的唯一情况是激活一个TSR程序，但TSR程序在退出之前有义务恢复原来的屏幕，如果它无法恢复屏幕的内容，那么这是它的责任，我们不会在自己的程序中去考虑屏幕内容会无缘无故消失这种情况，所以可以把屏幕看成是应用程序私有的。 如果程序输出的内容过多，如用dir显示一个含有很多文件的目录，用户根本无法看清快速上翻的屏幕，这时程序可以设计一个参数来暂停一下，如dir/p。这已经是DOS程序最体贴的做法了，如果用户想回过头去看已经滚出屏幕的内容，那可对不起，只能再执行一遍了！ 所以对DOS程序来说，程序想在什么时候输出信息那就是什么时候，根本不存在When这个问题。 但在Windows操作系统中，屏幕是多个程序公用的，用户程序不要指望输出到窗口中的内容经过一段时间后还会保留在那里，它们可能被别的东西覆盖，如其他窗口、鼠标箭头或下拉的菜单等。在Windows中，恢复被覆盖内容的责任大部分属于用户程序自己，理由很简单：Windows是个多任务的操作系统，假如程序B覆盖了程序A的窗口内容，覆盖掉的内容由程序B负责恢复的话，它就必须保存它覆盖掉的内容，但是在它将保存的内容恢复之前，程序A也在运行，并可能在程序B恢复以前已经向它自己的窗口输出新的内容，结果当程序B恢复它保存的窗口内容时，保存的内容可能是过时的(而DOS的情况就不同，TSR程序激活的时候，用户程序是被挂起的)，所以最好的办法就是让程序A自己来决定如何恢复。 Windows系统采用的方法是：当Windows检测到窗口被覆盖的地方需要恢复的时候，它会向用户程序发送一个WM_PAINT消息，消息中包括了需要恢复的区域，然后由用户程序来决定如何恢复被覆盖的内容。 如果程序因为忙于处理其他事务以至于无法及时响应WM_PAINT消息，那么窗口客户区原先被覆盖的地方可能会被Windows暂时画成一块白色(或者背景色)的矩形，或者根本就是保留被覆盖时的情形，直到程序有时间去响应WM_PAINT消息为止。我们常常可以看到这种情况发生在死锁程序的客户区内，这就是因为死锁的程序无法响应WM_PAINT消息来恢复客户区造成的。 所以对于When这个问题，答案是：程序应该在Windows要求的时候绘画客户区，也就是在收到WM_PAINT消息的时候。如果程序需要主动刷新客户区，那么可以通过调用InvalidateRect等函数引发一条WM_PAINT消息，因为在WM_PAINT消息中刷新客户区的代码是必须存在的，所以用这种看似舍近求远的办法实际上可以节省一份重复的代码。即使是在游戏程序这种