Board logo

标题: GTK+和X在嵌入式Linux中的应用 03 [打印本页]

作者: samwalton    时间: 2013-10-11 19:21     标题: GTK+和X在嵌入式Linux中的应用 03

 还可以使用一个更好的方法来完善字体管理系统,即包装GtkStyle,这样开发者就可以通过属性来获得一个窗口的字体,这比直接使用 X 系统字体的名字要更灵活。比如要显示一个比基本字体要大一号,并且是黑体字就可以调用:
  gtk_widget_set_font_bold (widget, TRUE);
  gtk_widget_set_font_enlarge (widget, 1);
  这是通过在 GtkWidget 结构中加入一个 GdkFont * font 来实现的,GtkWidget  是所有窗口类的父类。如果设置widget->font 那么就使用它,否则就使用widget->style->font。
  窗口管理
  在嵌入系统GUI中,还需要建立一个窗口管理器。我们可以选择一个开放代码的,轻量级的X管理器,Aewm。在嵌入系统中,我们会将最上层的窗口设置为获得焦点,并且只有对话框能移动,能显示其标题栏。
  窗口管理器是一个交互端,它可以管理内部与外部的应用程序的窗口。每一个应用程序的窗口,都会建立一个 socket 连接,并取一个名字。一个应用可以把请求将自己放在窗口堆栈的最下面,或者将一个命名的应用往上移。如果一个对话框要在最上层的窗口上打开,那么窗口管理器就将告诉这个最上层的窗口它将不再获得焦点,而新对话框将获得焦点。
  整体尺寸大小
  经过一系列的改进后,我们就得到了一个稳定的,功能和性能都能满足嵌入系统要求的GUI了。在arm系统下,得到的尺寸大小为:
  其中 GTK+ 里面仍然还有不需要的代码,可以将其再去除。如果再简化一下的话,GTK+ 可以做到850KB,总体大小可以到 2.8M。
  运行性能
  将修改过的 GUI 运行在一个 arm7 的系统上,CPU 为 100MHZ,运行时的效果还不错,窗口响应用户操作的速度很迅速,新的画面创建与显示的速度都能接受。
  但是,启动时的时间却有些问题,比较慢。在这个 CPU 上,应用程序画面加载与显示的时间需要 2.4秒,其中 1.5 秒是花在了建立与显示 UI 上。
  在较慢的 CPU 上,这样的启动速度是 GTK+ 运行在 X,X 再写到 framebuffer 上导致的。我们需要分析具体的瓶颈在什么地方。在深入的调试中,当使用PC机来运行我们的应用,而在ARM设备上显示时,初始化和显示的时间几乎可以忽略不计。同样,将应用运行在arm设备上,而在PC机上显示时,性能也很好。所以数据包的传输,framebuffer上的显示及GTK+的运算速度都不是问题所在。速度慢的原因可能是这几个因素的先后顺序引起的。而且内存的占用上也存在问题。在初始阶段,GTK+构造了大量的对象,GTK+和X是使用共享内存来通讯的,X写到 framebuffer,framebuffer也是不变地写到显存上。这些都是发生在一个较窄总线上相同的内存空间里,这个就会引起速度慢。
  现在知道了X在启动时比较花费时间。在客户模式下的GTK+的应用,需要连接到X  server,通过了认证,得到位深及其他资源。当然,使用X系统的好处要远大于它的不足。X系统提供了一个灵活的client/server模型,这样更有利于应用的灵活加入。你可以在同一时间显示不用的应用窗口,而像GTK+/Fb等其他的GUI方式无法做到这一点,当然QPE是个例外。
  2.4秒的延时,也并不能完全否定一切。在一个700MHZ的windows系统的PC上,Microsoft Word, Excel and IE几乎都需要2秒的时间来启动。KEdit, 一个KDE的应用程序,在500MHZ的PIII上,加载的时间也需要1.37秒。
  对于启动时间,需要采用其他的办法来加以改善。一个策略就是在用户等待的时候,显示一些东西来表示系统正在工作,这样会使用户忽略掉启动时间的缓慢。另一个策略就是可以预先在背后启动一些通用的程序,来有效减少集中启动的时间。这也是通常嵌入系统所惯用的做法。
  在arm7的系统上,由于没有浮点运算FPU,所以GTK+中的浮点运算部分最好是去掉,否则会大大影响性能。GTK+使用到的浮点变量只分布在少数的几个窗口中,并且去掉它们会带来3%到12%的性能提高。
  高像素的应用会导致速度较慢,这大多是由于GTK+与X中对高像素的效率低下的处理有关。如涉及到的XPM,XPM (X pixmap)格式是被设计来做到较好的兼容性,而不是更加快速。X系统是一个像素一个像素地画到server的pixmap的。GTK+的像素处理也很低效,它是使用fgetc()来读取XPM文件的,这就会带来大量的上下文切换开销。
  X窗口系统的结构也导致了像素的加载变慢。GTK+客户端需要加载,分析XPM文件,将像素值通过传输协议发送给server,然后server才将像素值放入framebuffer。如果客户端直接将数据写到framebuffer server那将会有效很多。
  处理的GTK+像素的办法就是,写一个临时的中间过程,取得render过的像素,使用这个原始数据来替换XPM数据,这个原始数据就可以直接强制写到X server上。从结构上来看,这虽然不是一个很好的处理办法,但在效率上却要比使用XPM要快上80%。
  总结
  现在的消费电子大多需要一个美观,实用的图形界面系统GUI。在嵌入系统linux下,有很多种GUI可供选择。使用开放代码的GUI的优点就是你可以将其裁剪得满足你的各种各样的特殊需求。GTK+就是一个很好的选择,而X-window系统提供了一个稳定可靠的client/server模型。当你得到一个只有2.9M大小的定制过的GUI时,对大多数的嵌入系统还是很有参考价值的。




欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/) Powered by Discuz! 7.0.0