【UE4】Slate界面系统

Slate界面系统
作为核心界面系统，Slate是一个跨平台的、硬件加速的图形界面框架，采用了
C++的泛型编程来允许直接使用C++语言撰写界面。
12.1 Slate的两次排布
Slate是一个分辨率自适应的相对界面布局系统，为了能够完成这样的目的，
Slate实质上采用了一个“两次”排布的思路。

1. 首先，递归计算每个控件的大小，父控件会根据子控件来计算自己的大小。
2. 然后，根据控件大小，具体计算出每个控件的绘制位置。
   由于有部分控件是“大小可改变”的，因此必须先计算出“固定大小”，才可
   能实际排布这些控件。
   12.2 Slate的更新
   Slate系统的更新，实质上是与引擎内部更新分开的。FEngineLoop类会首先更
   新引擎，随后在确保FSlateApplication已经初始化后，调用FSlateApplication
   的Tick函数进行更新。
   FSlateApplication代表了当前正在运行的Slate程序，F开头意味着这个类本
   身并非一个Slate组件，其只是行使“管理”的责任。
   从实际行为上看，FSlateApplication也确实是负责绘制当前窗口，当自身的
   Tick函数被调用的时候，它会请求更新所有的Window，即调用
   TickWindowAndChildren函数。随后才会调用Draw系列的函数，去绘制所有的对
   象。
   12.3 Slate的渲染
   需要注意的是，Slate的渲染并非是一个“递归渲染”的过程，而是一个“先准
   备，再渲染”的过程。
   所有的Slate对象将会首先准备需要渲染的内容，即WindowElement。然后这
   些内容会被交给SlateRHIRenderer负责，最终被绘制出来。
   Slate同样是借助虚幻引擎的RHI硬件绘制接口进行绘制的。所以Slate的绘制
   实际上走的是标准的渲染流程：
3. 将控件对象转换为需要绘制的图形面片。
4. 通过PixelShader和VertexShader来使用GPU进行绘制。
5. 拿回绘图结果，显示在SWindow中。
   值得强调的是，Slate的渲染是没有开启深度检测的。而且在
   SlateVertexShader中，每个渲染对象的Z轴均会被设置为0，这意味着：
6. 控件对象简单地按照绘制顺序堆叠，后一个控件将会直接叠加在前一个控件之
   上。
7. 控件对象不会存在一个更新区域的概念，这意味着即使被遮盖住的位置，依然
   会被绘制出来。
   当然，如果简单地逐控件进行绘制，那么每个控件将会产生一个DrawCall渲染
   请求，这是一个非常低效的过程，这将导致复杂界面的渲染速度非常低下。
   为了解决这个的问题，虚幻引擎采用了一个称为ElementBatch（对象批量渲
   染）的概念。为了能够引出这样的概念，我们不妨进行这样一番推理：
8. 有些控件对象实际上是可以同时渲染的，只要它们互相不重叠就可以。
9. 重叠的对象必须按照先后次序渲染。
10. 实际上来说，只有SOverlay、SCanvas这样的控件，才会产生控件对象堆叠，
    类似SVerticalBox这样的控件，是根本不会产生堆叠的。
    因此，如图12-2所示，对每个需要堆叠对象的层级编号增加1，就能够构成一个
    树状结构。其中如果是平级对象，如SVerticalBox，其子对象的层级编号相等。如
    果是SOverlay，其每一个子对象的层级编号，都是在其上一个子对象层级编号基础
    上加1。
    图12-2 Slate渲染层级示意
    于是我们会发现，处于同层级编号的几何对象，都是不产生堆叠和遮挡的。所
    以可以将这些对象同时进行渲染。对于上图中所展示的案例而言，这样的批量渲染
    方案，能够将渲染请求次数从5降低到3。对于真正的控件来说，渲染量将会降低得
    更为明显，因此这是一个相当取巧的方案。