挖坑网/填坑网 DebugDump Forum

别人挖坑默默填上,自己挖坑含泪填上。天下没有填不了的坑,只有不会填坑的人。来吧,加入我们,挖坑行,填坑你更行! 站长QQ: 516333132 点击这里给我发消息

您尚未登录。

#1 2018-02-20 22:04:56

晕哥
Administrator
注册时间: 1970-01-01
累计发帖: 2,482

Nuklear渲染机制分析 【转】

http://www.cnblogs.com/fightingCat/p/6034703.html

最近打算用C写个东西,想找个轻量的UI库,想起以前star过的一个repo,只有一个头文件约15000行的ANSI C代码,没有任何标准库以外的依赖。就是这个:https://github.com/vurtun/nuklear 。嗯,Nuklear,核动力。
看效果真心不错,让我想起另一个UI库zebkit,HTML5 canvas的。事实上这两个还真有点像,就是都是命令式绘制的。本来想照着demo用SDL做一个简单的界面出来,结果久别重逢C语言,一不小心把源码review了一遍(张全蛋:silly B stupid Chinglish。不不不,只是觉得说代码审查不对味儿...)。下面是简单的分析。

Nuklear用一个nk_context结构维护输入,风格,内存,剪贴板,命令队列,鼠标合成,窗口管理。对于一个nk_context实例,基本渲染流程为:
应用程序初始化后开始如下帧循环逻辑。

应用程序从平台相关接口获取输入事件,根据事件类型对nk_context调用nk_input_*等api,Nuklear将各类事件参数记录在nk_context中。注意前后要调用nk_input_begin和nk_input_end以初始化和再处理一些数据。

应用程序对nk_context调用nk_begin绘制窗口,Nuklear用窗口名和标题计算hash并在nk_context的窗口链表中查找,如果窗口不存在则创建并加入链表,否则只更新窗口的参数(如位置大小样式等)。同时,Nuklear还会在此时根据上一步骤中记录的输入事件处理窗口响应行为。

应用程序调用nk_layout_*、nk_button_*等api绘制布局和控件,Nuklear判断控件可见性并“绘制”控件,这里的绘制实际上是向nk_context的命令队列插入绘制命令。同时,Nuklear根据上一步骤中记录的输入事件处理控件响应行为。

应用程序对nk_context调用nk_end结束绘制窗口。

应用程序对nk_context调用nk_foreach宏,循环取出上一步骤中“绘制”控件时加入的绘制命令,并根据命令类型调用平台相关接口进行实际的绘制。

开始下一帧的循环。


总结起来,这个库实现轻巧,代码也用了一些技巧,看起来很干净。以个人的看法评价下优缺点:

首先,整个UI的驱动机制,从事件到渲染都是命令式的,nk_context只管理窗口并不维护控件的数据结构,应用程序需要自己维护数据,在绘制控件时传入。这样的好处是内存占用小,数据甚至可以只存在于栈中,而且命令式渲染可以很方便灵活地定制效果。

但是,控件的绘制和响应输入事件耦合在了一起,缺少独立数据结构导致应用程序需要协助维护控件状态,并在绘制控件时通过nk_context传入,比如last_widget_state表示控件一系列响应鼠标等输入事件的状态,这些本应该是应用程序不关心的。这里理解错了,这个状态只是在内部传递的,不过因为同时只能保存一个当前正在交互的控件状态,所以像渐变动画这种就做不到了。

其次,命令式绘制导致每帧都需要重复绘制,即使界面并没有发生变化。在源码开头的注释中提到定义NK_ZERO_COMMAND_MEMORY的宏可以在加入绘制命令到队列之前memset清零命令结构体,从而利用memcmp快速检查命令队列是否变化从而避免实际绘制(不清零会有随机数据无法比较)。然而找遍了源码也没有找到实际的使用,也没有提供相关的utils,如果需要自己实现的话感觉有点侵入式了。

最后,不得不说乍一看single header file的ANSI C代码似乎很好看,但是细看发现一些符号命名真是随意,创建窗口的api是nk_begin,源码中还有nk__begin(两个下划线),nk_start,nk_draw_begin,nk__draw_begin,虽然明白意图是私有符号,但是阅读起来真容易马虎。还有api动词名词就不说了,但是大括号换行和不换行两种风格夹杂,赋值语句对齐和不对齐交替,if语句不加花括号一会写在一行一会写两行。

自从当兵几年没用C还以为都忘干净了,重新拾起来吧。

离线

页脚