最近 raylib 比较火，又是移植 web 又是移植掌机，看了眼 raylib 的例子代码，知道它为什么代码量那么少了，它甚至连一个显示对象树/场景树都没有实现，就是直接调用各种 draw 函数，和 ImGUI 一样属于 “立即模式”，这种模式做点简单的东西很舒服，对象一多一复杂就会比较麻烦：

那么这种每帧控制自己绘制的立即模式有啥问题呢？

第一：程序简单的时候好像也没区别，程序复杂了性能会急剧降低；

第二：正统图形引擎，都是维护一颗显示对象树/场景树，使用者将模型添加到书节点上，然后引擎能根据摄像机位置，高效剔除不需要显示的东西，raylib 这种立即模式相当于将大量工作，比如显示对象剔除，坐标变换等全部一古脑的推给用户，图形简单时可以不做剔除，但场景稍微复杂点不做剔除性能就会急剧下降；

第三：需要显示的对象多了以后，如果两帧之间大部分对象并没有改变，那么使用显示对象树可以基本不管，而立即模式下即便大量物体没改变也需要全部重新过一遍，大量数据重复传输到显存；

第四：对象多了以后，对脚本不友好，脚本调用 C 接口本来就缓慢，传统引擎脚本只需要维护两帧之间真正改变的对象，连动画这些自动的东西一旦开始都不用管，但立即模式下，所有对象每帧都需要用脚本操作一遍，开销巨大；

立即模式用来做 UI 问题不大，游戏界面本身没多复杂，但有序图形实用性就不太高了，所以 raylib 这样的立即模式图形引擎，更适合作为教学工具，而不是用于实际项目。