byte col_f; // 物件的前景颜色
byte col_b; // 物件的背景颜色
byte att; // 物件的其它显示属性
ACT_Struct (*act)[]; // 该物件的响应动作表指针
byte *note; // 导航说明信息
}UI_Struct;
图4：Pixelworks的GUI Builder OSD
UI开发工具界面。
这样的结构是为了描述一个OSD物件的基本属性及规定其对于动作的相应表现。利用这样的结构将场景中的每个物件描述清楚，则一个特定UI场景的OSD内容就可以被确定，而同时被确定的还有其上一个场景、下一个场景及动作响应特性等所有UI特性。这样的信息构成一个数组，由一个统一的“解释平台”对其进行翻译和描述，从而将整个UI构造完成。
这有点类似解释语言，而我们所需要做的就是编写这些“脚本”，对物件进行OSD“绘制”的工作由“解释”平台去调用外部的OSD发生器的驱动代码来完成。当需要改变OSD发生器或基于不同平面显示控制器平台时，只需要更新少量OSD部分驱动代码，从而实现UI系统“平台无关化”。
我们需要构造相关物件的数据结构，以便“解释”平台识别物件类型并进行正确的绘制。例如下面的结构完成了一个语言选项(文字物件)的描述：
void UI_ChangeLan()
{
UI_Lan=VAL_Lan;
ReDraw();
}
code byte *STR_LAN_CHN[]=
{
“中文”,
“英文”,
“法文”,
“西班牙文”,
};
code word TXT_LAN_CHN[]=
{
//文字物件的标志 对应的文字资源 对应的变量 具有的可选项目总数 当该物件被改变时的执行动作
RES_TXT,STR_LAN_CHN,VAL_LAN,sizeof(STR_LAN_CHN)/sizeof(byte *),UI_ChangeLan
};
第一个数据RES_TXT向“解释”平台表明这个物件是文字，具有文字的数据结构。“解释”平台依据这一点，按照事先约定的结构读取后继数据，第二个数据表明其文字内容的来源是STR_LAN_CHN，第三个数据表明需要根据哪个变量来决定获取文字资源中第几个数据，而第四个数据表明，该物件具有多少个可供选择的文字内容，最后一个数据规定了当该物件发生改变时需要做什么。这样，“解释”平台获得了足够的信息去“绘制”这样一个语言选项，并可以在发生改变时去自动执行UI_ChangeLan()这个函数，帮助程序员去完成语言改变所需要进行的操作。
本文相关DataSheet：
事实上，所有这些结构完全可以进行定制，只要与“解释”平台保持一致就可以了。
利用这样一个驱动结构，一旦“解释”平台构建完成，OSD开发人员需要做的就变成利用平台支持的各种物件积木，进行摆放、堆积来构造OSD图形表现，而不必要重复编写实现代码和关心与特定硬件平台相关的驱动代码细节。
更进一步，甚至连这些积木的摆放和设计，我们可以设计一个直观的Windows应用程序来完成诸如图形-->字符元件生成器、OSD图形界面设计，以及最终的资源文件和UI资料数组的生成，并与底层的“解释”平台进行联接编译，得到最后的MCU代码。
这样的OSD界面开发环境会摆脱抽象、枯燥和低效率，变得直观、有趣，甚至可以由客户自己设计相关的OSD的界面，而完全不需要经验和对OSD底层驱动的了解。
需要指出的是，相较传统的if else，结构化的OSD UI处理机制会带来最终程序体积的增加和运行速度的变慢，但是这些缺点在MCU内部程序空间不断增加和支持的时钟频率不 断提高的情况下是微不足道的。所以，如果读者面对的案例是对MCU处理速度和程序存储器受限的情况下，可能并不适用这样的方案。以笔者开发的液晶电视项目为例，在支持所有电视功能、图文、丽音及游戏、日历等附加功能的情况下，基于MCS51的多任务系统的总程序小于32KB，而基于Myson MTV230的OSD+MCU处理器的运行速度非常快，并不会感到任何延迟。而通常支持位图OSD的开发环境使用的是X86或更快速的ARM等处理器，并具有大于2MB的程序存储空间。
