自定义 Shader 内容生成

[0x1306a94]

@domchen
figma 里面 fill 可以使用自定义的 shader 来生成内容。
而目前 tgfx 的 Shader 只能使用内置实现的。RuntimeEffect 可以自定义渲染，但是依托于 ImageFilter
而 ImageFilter 是用于后处理，而非原始生成颜色。

不知道是否有考虑提供 SkRuntimeEffect 类似的支持

[Hparty]

感谢建议！现状确实如你所说：

1. 为什么现在没做。tgfx 要同时跑 GL/Vulkan/Metal/WebGPU，RuntimeEffect 的做法是把最底层开放出来——你直接用当前后端的原生着色语言（重写 onDraw 操作 CommandEncoder），自由度开到最大，不做中间层的限制。所以能力上业务方已经可以自足：想生成什么内容都可以自己实现。原生支持 SkRuntimeEffect::MakeForShader 的价值主要剩两点——性能（作为颜色源直接画，不用像变通方案那样多一次离屏 RT）和易用性（一份代码跨后端、能作为真正的 Shader 参与 Blend 等组合）。但要做到那样得引入一套着色语言编译器或跨后端 IR，相对这两点收益，投入产出不划算，所以一直没排期。

2. 现有能力下怎么实现自定义填充。三条路：一是用 RuntimeEffect 做 ImageFilter，onDraw 里忽略源图、自己输出颜色，重写 filterBounds 扩大输出范围，再画个占位矩形挂上 filter；二是离屏画成 Image 后用 Shader::MakeImageShader 填充；三是更彻底——直接用 tgfx/gpu 的公开接口（Device / CommandEncoder / RenderPipeline）自己管理 pipeline 绘制，RuntimeEffect::onDraw 拿到的 CommandEncoder 就是这套接口。都能用，就是没有 runtime shader 来得直接。

3. 以后会不会做。这个方向我们考虑过，但按现有架构实现起来难度不小，短期不会排期。方便的话可以说说你的具体场景——比如需要传哪些 uniform、要不要采样别的纹理（child shader）、是否要求一份代码跑所有后端——真实需求对我们后面评估方案很有帮助。

[0x1306a94]

我试了下 figma 的 shader fill 后面是 figma 自己的AI 生成的 shader

看着效果应该就是非常纯粹的假定在一个矩形内绘制。然后按顺序执行，应该是一个模版化的
就像 shadertoy 网站一样，只需要自己实现 mainImage 无需去处理其它复杂的GPU交互。
需要使用时，只需要编写 shader 传入 uniform 需要纹理话传入纹理，就能简单一小段代码实现预期的效果
这样移植 gl-transitions 这些网站提供效果就很容易

至于你说的需要引入一套着色语言编译器或跨后端 IR。我感觉按照 tgfx 现在的发展路线其实可以不用的。
就像前段时间讨论过的 Metal 后端使用SPIRV 将GLSL 转为 MSL 耗时问题。当时说的后续的计划是逐步迁移到离线化转化

所以开发者只需要照常用GLSL 编写就行了。通过离线化工具自动转化。Shader 的设计本应该就是一个模版化轻量化的，但就是这个轻量化的方案
可以很方便的实现一些特别的效果。

而 RuntimeEffect 是作为一个最大自由度的方案，用于实现一些 Shader 轻量化所不能实现的复杂效果

diagnostic(off,derivative_uniformity);

struct Uniforms {
  frameData: vec4f,
  inputDimsData: vec4f,
  rippleCount: vec4f,
};

@group(0) @binding(0) var<uniform> u: Uniforms;

struct VsIn {
  @location(0) pos: vec2f,
  @location(1) uv: vec2f,
};

struct VsOut {
  @builtin(position) position: vec4f,
  @location(0) uv: vec2f,
};

@vertex fn vs_main(in: VsIn) -> VsOut {
  var out: VsOut;
  out.position = vec4f(in.pos, 0.0, 1.0);
  out.uv = in.uv;
  return out;
}

@fragment fn fs_main(@location(0) outputUv_in: vec2f) -> @location(0) vec4f {
  let time = u.frameData.x;
  let outputUv = outputUv_in;
  let dims = max(u.frameData.yz, vec2f(1.0));
  let inputDims = max(u.inputDimsData.xy, vec2f(1.0));
  let inputTexel = vec2f(1.0) / inputDims;
  let uv = outputUv;
  let texel = inputTexel;
  let aspect = inputDims.x / max(inputDims.y, 1.0);
  let rippleCount = u.rippleCount.x;

  // Aspect-correct coordinates centered at layer center
  let p = (uv - vec2f(0.5)) * vec2f(aspect, 1.0);
  let dist = length(p);

  // Sinusoidal ripple wave
  let wave = sin(dist * rippleCount * 6.2831853 - 0.0) * 0.5 + 0.5;

  // Gentle radial falloff toward edges
  let falloff = 1.0 - smoothstep(0.3, 0.7, dist);

  // Blue-to-white water palette
  let deepBlue = vec3f(0.04, 0.18, 0.55);
  let midBlue  = vec3f(0.15, 0.55, 0.9);
  let white    = vec3f(0.85, 0.95, 1.0);

  var color: vec3f;
  if (wave < 0.5) {
    color = mix(deepBlue, midBlue, wave * 2.0);
  } else {
    color = mix(midBlue, white, (wave - 0.5) * 2.0);
  }

  // Apply falloff: fade to deep blue at edges
  color = mix(deepBlue, color, falloff);

  return vec4f(color, 1.0);
}

[Hparty]

明白你的需求了——轻量 shader 填充器。其实这个不用等引擎支持，外部现在就能简单搭出来：

模板部分是固定的：固定 vertex + 你的 fragment + uniform 绑定。用 RuntimeEffect 的 onDraw 拿到 CommandEncoder，pipeline 建一次，之后每次只换 fragment 代码和 uniform 数据——相当于自己实现一个 shadertoy 壳，代码量不大。要当 fill 用的话，输出到纹理包成 Image，再 Shader::MakeImageShader 填充即可。

这个"外部搭模板壳"的用法后续很可能成为官方最佳实践，我们也鼓励业务方这么做——这类需求业务属性很强，引擎不会内置穷举各种模板，由业务方按自己的场景组装最灵活。引擎要补的只剩中间一环：GLSL 到各后端语言的离线转换。到时候你还是写 GLSL fragment，转换由引擎工具链接管，直接当 shader 使用。所以方向不冲突——你现在搭的壳，将来换成官方入口也只是扔掉模板代码，fragment 完全复用。

[0x1306a94]

好的呢

[0x1306a94]

https://github.com/0x1306a94/MotionStudio/blob/feature/runtime_shader/adapter/tgfx/tests/RuntimeShaderTest.mm 大概是这样对吗？然后再给完善一下

另外 MakePlaceholderImage 是每一个Shader 单独构造一个，还是可以所有的都复用。
而 pipeline uniformBuffer 这些和 GPU 关联的，应该是在 onDraw 根据进行创建和缓存
可以参考 pag 里面的 RenderCache 当 context->uniqueID() 变化了就清空缓存。

[Hparty]

看了下你的 RuntimeShaderTest.mm，整体没问题，就是这个思路。回答你的问题，另外有个坑要提醒：

1. placeholder 复用一个就行，不用每个 shader 都建。Image 创建完就不可变了，线程安全，这里它只是凑 makeWithFilter 要求的非空 source，内容根本不会被读到，全局 static 一个就够了。

2. 缓存的理解对，但 pipeline 建议挪到 onDraw 里建。 你现在是在构造函数里拿外部 context 的 gpu 建的，context 重建之后（uniqueID 变了）pipeline 就失效了，实例跨 context 用也会绑错 device。在 onDraw 里用 encoder->gpu() 懒建，按 context->uniqueID() 当 key 缓存，变了重建就行，就是 pag RenderCache 那个思路。uniform buffer 也一样，别每次 onDraw 都 createBuffer，留一个反复复用，每帧只更新数据。shader 编译挺贵的，Metal 上 GLSL 要转 SPIR-V 再转 MSL，pipeline 不缓存的话开销会很难看。

3. gl_VertexIndex 别用，这是个坑。 RuntimeEffect 的 shader 约定的是 GLES 写法，GL 后端是把代码原样丢给驱动编译的，gl_VertexIndex 是 Vulkan 方言里的，GLES 没有这个东西（#version 450 在 ES 里也不合法），到 GL 上肯定编译不过。你在 Metal 上能跑是因为内部走了 shaderc 按 Vulkan 环境编了一道，碰巧认了它。fullscreen triangle 建议直接传 3 个顶点的 vertex buffer，CornerPinEffect 就是这么写的，三端都没问题。

shader 写法这个文档里确实没讲清楚，注释说的是"用当前后端的着色语言"，和实际约定对不上，我们后面把注释改一下。

[0x1306a94]

感谢

[0x1306a94]

这是实现后的效果，非常感谢您的指导。
另外 tgfx 后面是否可以考虑提供一个公开的 shader 编译检查接口呀？
现在只能靠运行时的错误日志

2026-08-07.14.12.28_compressed.mp4

[Hparty]

这个需求我们评估了下，暂不打算做成 tgfx 的公开接口，业务侧自己校验成本更低：

1. 离线校验直接用 glslangValidator 或 shaderc 的 glslc 扫一遍 GLSL 就行。tgfx 的 Vulkan/Metal/WebGPU 后端内部走的也是 shaderc 编译链，glslc 能过基本等价于这三个后端能编译通过，开发期挂个 CI 或本地脚本即可。

2. GL 后端没有中间编译层，shader 代码原样交给驱动编译，最准的校验方式就是起个 GL context 调 glCompileShader 看 infoLog——这个在业务自己的开发环境做一次就行，不需要真机跑渲染。

3. 运行时编译失败的错误日志（带源码和 infoLog）目前也会打到 error log，配合前两步基本能覆盖定位。

做成公开接口性价比不高：GL 的校验必须依赖真实 GL context，没法做成"纯离线"的；其余后端本质上只是包一层 shaderc，业务方自己接 glslc 反而更灵活，还能和现有的 shader 模板工具链整合在一起。

更顺的时机是以后做离线 shader 预编译的时候——那时工具链本身就要把 GLSL 转到各后端产物，编译校验是天然附带的能力。现在单独做一个运行期校验接口，到时候反而成了要兼容的历史包袱。

[0x1306a94]

好的呢。

另外想再问问，您们有计划为pagx 或者 pag 添加这种自定义shader 的能力。
figma 目前 fill stroke effects 都支持 自定义shader 以及它自己的AI生成shader
而 Ardot 对标 figma 是不是也会实现类似的功能呢。
如果能够支持的话，那么一些效果就不用通过预先光栅化了

[Hparty]

有的，后续会支持的，已经在策划当中了