# 渲染管线 > 一个像素如何抵达屏幕 —— Paint → 按图元的渲染器 → OpenGL —— 以及什么是 batching。 Source: https://crossfly.dev/zh/docs/concepts/rendering-pipeline — CrossFly documentation. Full docs as one file: https://crossfly.dev/llms-full.txt # 渲染管线理解绘制如何变成像素，就能解释框架的多条性能规则。

## 绘制的各个层次 - **`Paint`** 是你在 `onPaint(...)` 中用来绘制的门面。它以**本地坐标**、 **clip** 和**平移**来思考 —— 并且**完全不了解 shader** 或 OpenGL。你说"在这里画这个矩形"；至于它如何变成三角形和 GPU 调用，那不是你要操心的。 - **`gl` / 渲染器** —— **每种图元都有一个专用渲染器**（矩形、圆角矩形、线、文本、图像……），每一个本质上都是一个 shader。`Paint` 把工作委派给正确的渲染器。 - **OpenGL** —— 最终的 *draw calls*。 ## 核心概念：batching 渲染器会把**同一类型**的绘制批量（batch）在一起，以减少 GPU 调用。由此推导出一条规则： > **切换图元类型会"关闭"前一个 batch。** 绘制顺序始终被保留，但 > 交替类型（矩形 → 文本 → 矩形 → 文本）会强制多次 flush；**把同一类型的调用 > 归拢在一起**才是带来性能的关键。实践中，在繁重的自定义绘制里，把所有矩形一起画完再画所有文本，比交替绘制的性能更好。 ## 按需渲染 + 整树重绘渲染模型的两个特性会影响你编写 `onPaint` 的方式： - **按需：** 屏幕**只有在有人请求时才重绘**（`repaint()` → `requestRendering()`）。没有请求，就不会生成新帧 —— 这能省电。（其线程相关的视角见 [paint thread](/docs/concepts/the-paint-thread)。） - **没有*脏矩形*：** 当一帧发生时，**整个可见树都会被重绘**，而不只是改变的那部分。不存在局部重绘。其实际后果是一条原则： > **让 `onPaint` 保持廉价。** 它在每个渲染帧都会对整棵树运行一遍 —— 不要在其中 > 分配对象、加载资源或做昂贵计算。 ## 一帧如何组装（高层视角）在每个渲染帧，`EventsProcessor` 绘制**窗口栈**（通过 `paintWindows(...)`）：栈顶窗口在上，下方窗口在后（弹窗会让前一个窗口仍然可见）。每个可见组件都会收到它的 `onPaint(Paint)`。 ```java // onPaint 最小且廉价：复用临时对象，在本地坐标中绘制（0,0 = 左上角） @Override public void onPaint(Paint paint) throws Exception { paint.rect(scratch.bounds(0, 0, width, height).fill(bg)); // 'scratch' 是一个可复用的 GRect } ``` ## 参见 - 应用：[自定义绘制](/docs/ui/images-and-graphics/custom-drawing) - 下一篇：[paint thread](/docs/concepts/the-paint-thread)