• 游戏引擎/GUI的设计与实现-常见GUI架构


    以X Window为代表的客户/服务器架构。

    X Window通常是指X服务器及封装了通信协议的客户端库。服务器端主要负责输入事件的分发,窗口层次的管理,以及显示输出的处理,其它功能基本上都是在客户端实现了。我们看到的各种界面元素都是在客户端绘制的,这一部分通常称为ToolKit,应用程序开发者只需要关注ToolKit就行了。以前的ToolKit非常多,经过多年的进化和淘汰,常用的ToolKit主要是GTK+和QT两个了。X Window是非常复杂和晦涩的,以前我花了不少时间去研究用于嵌入式系统的TinyX,有兴趣的朋友可以看我的博客X Window研究笔记

    要注意的是X Window的窗口管理功能是在X服务器里实现的,但窗口管理器却是一个客户端进程。窗口管理器决定了桌面系统的整体风格,窗口管理器进程通过窗口管理协议,发送请求给X服务器,由X服务器执行真正的窗口管理功能。这是X Window七大设计原则中的,提供机制而不是策略的一个体现。这样的好处在于,窗口管理器可以独立发展:比如用于嵌入式系统的窗口管理器和传统PC的窗口管理器之间的差别是很大的,独立出来后就可以开发两个不同的窗口管理器,分别用于不同的场景。

    Android上的实现也是客户/服务器架构。但是它和X Window并不完全相同,首先应用程序与服务器使用binder而不是socket作为IPC机制,这主要是出于性能和安全权限控制考虑。其次是窗口管理、渲染输出和输入事件分发是在几个不同的服务里实现的。

    以DirectFB为代表的Master/Slave架构。

    DirectFB可以单进程运行也可以多进程运行,多进程运行需要各进程之间协作,以防止显示错乱。在多进程运行方式下,DirectFB使用了一个所谓的主从(Master/Slave)模式,它有一个叫Fusion的内核模块,每个DirectFB进程通过文件接口与Fusion模块交换数据,第一个启动的DirectFB进程称为Master,后面的启动的DirectFB进程称为Slave,Master进程一般不能退出,否则Slave进程也会被迫退出。

    Master进程负责读取输入设备的输入事件,然后根据情况分发到各个Slave进程。窗口等信息放在共享内存中,窗口管理器通常是作为一个模块在各个进程中,后来DirectFB也支持了独立进程的窗口管理器。

    DirectFB说Master/Slave模式与C/S模式相比有更高的性能,但是我觉得真正的性能瓶颈是在界面的绘制上,进程间通信的开销非常小,Master/Slave模式根本没有什么必要。Fusion模块好长时间都没有稳定下来,我被它折腾了好几年,呵呵,现在想起来还有点恼火。

    以传统嵌入式GUI为代表的单进程架构。

    功能机时代的展讯和MTK的手机平台,以及现在的一些实时操作系统,整个系统都是在一个地址空间运行的,所有应用程序的数据都是共享的,虽然没有明显的创建进程,但是可以把整个系统看作一个进程。GUI在其中一个线程里运行,应用程序只是逻辑上的划分,物理上都是在一个进程中运行,所以他们不需要进程间通讯机制。

    在这种架构下,GUI实现相对简单,不需要进程间通讯机制,也不需要加锁(虽然有多个线程,但GUI的访问是串行的),GUI运行效率很高。它的不足在于稳定性存在潜在的问题,就GUI本身来说,因为其简单性而具有更高的稳定性,但是由于全部应用程序共享同一个内存地址空间,某个应用程序崩溃掉会导致整个系统崩溃。不过这不是GUI的问题,而是系统的问题。

    以前我写的嵌入式GUI FTK就是单线程的,这样做的主要原因是:1.FTK是为嵌入式系统开发的,所以希望能兼容各种实时操作系统。2.希望做得简单些,适用于轻量级的应用,没有必要搞的像GTK+那样强大。3.尝试一种新的架构,全部有界面的应用程序都在一个进程中运行,其它服务器在后台运行,彻底分离界面与逻辑。

    基于浏览器HTML5 Canvas的GUI。

    创新高性能移动UI框架——Canvas UI 框架认为Canvas UI是HTML5 APP的界面发展趋势,我在几年前就认为Canvas UI才是HTML5 APP的未来,所以花了大量时间去开发CanTKAppBuilder/GameBuilder

    基于浏览器HTML5 Canvas的GUI的架构类似于单进程的架构,主要区别有:

    • 浏览器已经封装了输入设备,GUI不要从输入设备里读取事件,只需要注册相应的回调函数即可。

    • 浏览器已经实现了主循环,GUI可以通过requestAnimationFrame注册回调函数。

    • GUI无法直接唤起输入法,只能通过input元素来模拟,也就不需要去实现编辑器控件。

    • GUI 不需要自己实现基本的绘图操作,Canvas已经提供了强大绘图操作。

    • 不需要太关心跨平台的东西(各个浏览器存在兼容性的问题,还好Canvas的API差异不大)。

    不同的GUI的架构适用于不同的情况,需要根据实际情况选用。对于大多数人来说,去实现一个完整的GUI的机会不多,了解一下就够了。

  • 相关阅读:
    canvas
    学习总结
    后台管理人员项目,添加和查询的思路
    写了项目的一些心得
    学了一丢丢的正则皮毛
    已学的前端存储(学生)
    $.ajax()方法详解即自己遇到问题(新手)
    C#中 decimal 的四舍五入
    自己写一个C#数据结构:用List<T>实现一个简单的Stack
    【转】在CentOS 6.X上部署C# 开发环境
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13333023.html
Copyright © 2020-2023  润新知