在嵌入式 linux 下有很多图形界面系统 GUI,包括 Qt/Embedded,FLTK,Microwindows 和 GTK+ 等。作为一个开发者,到底使用什么样的 GUI 系统呢?对一个系统,将它改造为符合你的需求,你要做多少修改呢?修改后的系统的尺寸一般会有多大呢?这些都是开发人员会遇到的问题。我们在这里讨论的就是要对这些内容做一个具体细致的分析,通过我们的讨论,大家会对基于 GTK+ 和 X 的 GUI 在嵌入式Linux 下的应用有一个确切的了解。
1、 X-window 系统与 GTK+ 都非常稳定可靠,X-window 系统是经历了长期的开发及应用实践的,GTK+ 也是一个比较成熟的开放源代码项目; 2、 X-window 系统是一个灵活的 client/server 的模型结构,一个应用客户端的崩溃不会影响到图形系统的其他部分,这是一个很重要的特性,它有利于支持第三方应用的扩展开发,而不影响到主体部分; 3、 GTK+有两个重要的库:GDK和GLIB。GDK抽象了底层的窗口管理,要移植 GTK+ 到另一个不同的窗口系统的话,我们只需要移植 GDK 就可以了。GLIB 是一个工具集合,它包括了数据类型,各种宏定义,类型转化,字符串处理,任何应用程序都可以链接这个 GLIB 库,使用其中的各种数据类型、方法,来避免重复代码,或者说避免开发人员重新发明轮子,这样有利于减少整个系统的尺寸; 4、 对 GTK+/X 的裁剪是很容易的,它们有着很好的可配置的选项,有着清晰的代码结构,可以保证安全正确地去掉大段的不需要的代码; 5、 GTK+ 有着大量的应用,GTK+ 已经被用在了很多重要的应用系统中; 6、 GTK+ 的授权是 LGPL 方式的,X 是 non-copyleft free license 的,第三方开发的系统都能与它们进行链接; 7、 GTK+/X 二者都是基于 C 代码的,而不是C++; 8、 GTK+ 使用 C 来实现了面向对象的架构;
1、 Qt/E 是其中较高级的,它是一个完整的,基于 framebuffer 的 GUI 系统,由 Trolltech 公司开发; 2、 Qt/E 有着高效的图形渲染效果,还包括 TrueType 字体系统,及 alpha blending 半透明处理; 3、 但 Qt/E 不是使用 LGPL 授权方式,而是使用两种授权方式:开发使用 GPL,而商用需要授权与版税; 4、 Qt/E 是用 C++ 编写的; 5、 Qt/E 非常大,一个 ipAQ QPE 就包括了 3.3MB 的 Qt/E 库和一个 718KB 的 QPE 库(和 Xlib 类似的一种库); 6、 Qt/E 不够稳定,QPE demo 不错,但出现过崩溃; 7、 FLTK (the Fast Light Toolkit) 是一个小型的 GUI 图形系统,它也是用 C++ 写的,特性太少,应用范围较少,不够成熟; 8、 Microwindows 和 X-Window 相比也是一个不错的选择,它占用大约 100KB-600KB 大小的内存,和文件存储空间,虽然已经有了一个其上的 GTK+ 移植,但还是不够成熟;
最开始,我们把不需要的 Widgets 去除掉,比如:GtkGamma、GtkHRuler、过时了的 GtkList(被 GtkCList所替代了)、和我们不需要的 GtkFrame 边框。
接着,修改Widgets的大小与绘制方法,GTK+提供了一个主题引擎机制,来控制窗口的外观与效果。它允许在运行中设置字体,设置行间隔,设置绘制特性。这样的机制很不错,但不够灵活,代码中很多设置的地方都是使用硬编码的方式;另外,一种主题,就是一堆额外的代码段和参数,这样会增加整体的尺寸。
GTK+总是假定一个窗口里面包含了另一个窗口,它们就是嵌套关系。但对于我们经常会碰到的有软键盘的应用时,就不完全正确了。软键盘虽然是属于一个窗口的,但却会超出那个窗口。所以为了突破这个假定,需要对GtkWindow增加一些特性,将软键盘处理成一种特殊的子窗口。
gtk_widget_set_font_enlarge (widget, 1);
窗口管理器是一个交互端,它可以管理内部与外部的应用程序的窗口。每一个应用程序的窗口,都会建立一个 socket 连接,并取一个名字。一个应用可以把请求将自己放在窗口堆栈的最下面,或者将一个命名的应用往上移。如果一个对话框要在最上层的窗口上打开,那么窗口管理器就将告诉这个最上层的窗口它将不再获得焦点,而新对话框将获得焦点。
经过一系列的改进后,我们就得到了一个稳定的,功能和性能都能满足嵌入系统要求的GUI了。在ARM系统下,得到的尺寸大小为: 其中 GTK+ 里面仍然还有不需要的代码,可以将其再去除。如果再简化一下的话,GTK+ 可以做到850KB,总体大小可以到 2.8M。
但是,启动时的时间却有些问题,比较慢。在这个 CPU 上,应用程序画面加载与显示的时间需要 2.4秒,其中 1.5 秒是花在了建立与显示 UI 上。 在较慢的 CPU 上,这样的启动速度是 GTK+ 运行在 X,X 再写到 framebuffer 上导致的。我们需要分析具体的瓶颈在什么地方。在深入的调试中,当使用PC机来运行我们的应用,而在ARM设备上显示时,初始化和显示的时间几乎可以忽略不计。同样,将应用运行在ARM设备上,而在PC机上显示时,性能也很好。所以数据包的传输,framebuffer上的显示及GTK+的运算速度都不是问题所在。速度慢的原因可能是这几个因素的先后顺序引起的。而且内存的占用上也存在问题。在初始阶段,GTK+构造了大量的对象,GTK+和X是使用共享内存来通讯的,X写到framebuffer,framebuffer也是不变地写到显存上。这些都是发生在一个较窄总线上相同的内存空间里,这个就会引起速度慢。
2.4秒的延时,也并不能完全否定一切。在一个700MHZ的windows系统的PC上,Microsoft Word, Excel and IE几乎都需要2秒的时间来启动。KEdit, 一个KDE的应用程序,在500MHZ的PIII上,加载的时间也需要1.37秒。 对于启动时间,需要采用其他的办法来加以改善。一个策略就是在用户等待的时候,显示一些东西来表示系统正在工作,这样会使用户忽略掉启动时间的缓慢。另一个策略就是可以预先在背后启动一些通用的程序,来有效减少集中启动的时间。这也是通常嵌入系统所惯用的做法。 在ARM7的系统上,由于没有浮点运算FPU,所以GTK+中的浮点运算部分最好是去掉,否则会大大影响性能。GTK+使用到的浮点变量只分布在少数的几个窗口中,并且去掉它们会带来3%到12%的性能提高。
处理的GTK+像素的办法就是,写一个临时的中间过程,取得render过的像素,使用这个原始数据来替换XPM数据,这个原始数据就可以直接强制写到X server上。从结构上来看,这虽然不是一个很好的处理办法,但在效率上却要比使用XPM要快上80%。
现在的消费电子大多需要一个美观,实用的图形界面系统GUI。在嵌入系统linux下,有很多种GUI可供选择。使用开放代码的GUI的优点就是你可以将其裁剪得满足你的各种各样的特殊需求。GTK+就是一个很好的选择,而X-window系统提供了一个稳定可靠的client/server模型。当你得到一个只有2.9M大小的定制过的GUI时,对大多数的嵌入系统还是很有参考价值的。 |
Powered by Discuz! X3.4
Copyright © 2001-2021, Tencent Cloud.