Microwindows图形编程机制

Microwindows从原理上采用分层设计的方法,每层次完成特定的功能,并且能够在不影响其它层次的基础上针对不同的应用进行改编或者重写。在最底层,显示屏、鼠标、触摸屏等的驱动程序提供了与交互相关的硬件设备的访问;中间层是一个精简的图形引擎,提供了划线、区域填充、多边形等多种基本的图形功能;最上层为图形应用程序提供了丰富的编程接口函数(API),通过这些接口函数可以定制桌面和窗口的外观。目前Microwindows提供两套API接口,以便能够更好地适应不同平台应用程序的移植,即 与Win32/Win CE基本兼容的API以及采用X体系的Nano-X API。
设备驱动层
设备驱动程序的接口定义在device.h文件中。中间层提供的与设备无关的图形引擎例程就是通过调用设备驱动程序跟硬件设备交互。这就保证了当平台硬件设备发生变化的时候,只需要改写相应的驱动程序,而无需修改上层代码。Microwindows提供基于Linux2.4.X内核的FrameBuffer设备驱动程序。FrameBuffer在Linux系统中通过/dev/fb0设备文件进行工作,通过mmap()系统调用将显示缓存映射至系统内存中。
设备无关的图形引擎层
Microwindows系统中最核心的图形函数是在图形引擎层通过调用下层的硬件设备驱动程序实现的。用户应用程序通常不直接调用引擎层的例程,而是调用最上层所提供的编程接口。将核心的图形引擎例程独立于应用程序接口主要是基于以下考虑：核心的例程在Client/Server环境中总是驻留在Server端,这些例程调用的位图与文字格式经过优化处理,使得执行速度更快,所以这些格式通常与应用程序所使用的不同。另外,核心例程常使用指针以产生更复杂高效但逻辑性较差的代码,而不是采用应用程序通常使用的ID号。在Microwindows的源代码中,核心的例程通常包含在Devdraw.c、Devclip.c、Devmouse.c、Devkbd.c和DevpalX.c文件中：
设备上下文
应用程序必须在调用图形绘制API函数前设置设备上下文。一些信息如目前采用的坐标系统、当前窗口在程序执行过程中相当长的时间内是不变的,所以没有必要传递给每一个调用的函数,因而可以通过设备上下文的设置,将这些相对持久的信息通知系统。同时,如当前前景色、当前背景色等很多属性也应在设备上下文中设置。可以通过调用GetDC来得到目前的设备上下文,当结束一系列绘制以后,调用ReleaseDC函数释放DC对象。
消息传递机制
在Microwindows API之间最基本的通讯机制是消息传递。一个消息包含有一个约定的消息号、两个参数：wParam和lParam。消息被存储在应用程序的消息队列中,可以通过调用函数GetMessage()获取。当等待消息时,应用程序被阻塞。一些消息和硬件事件相关,如WM_CHAR代表键盘输入、WM_LBUTTONDOWN代表鼠标左键按下。同时,窗口的创建与消除事件分别对应WM_CREAT和WM_DESTROY消息。在通常情况下,每个消息都对应于一个用HWND标识的窗口。在获取消息后,应用程序通过调用DispatchMessage()将消息分派到所对应的窗口进行处理。当窗口建立时,该窗口所对应的各种消息的处理函数同时被定义,所以系统知道向哪一窗口传递消息。 消息传递机制允许核心的API通过对应各种事件的消息传递来实现各种功能,如窗口的创建,绘制,移动等等。通常情况下,相关的窗口操作消息都由DefWindowsProc函数来进行默认的处理,这样就使得所有窗口的动作在行为上具有一致性,当某一窗口需要特殊的操作时,用户可以通过改写处理程序来满足要求。 可直接处理消息的函数包括SendMessage、PostMessage、PostQuitMessage、GetMessage和DispatchMessage。