WPF + HLSL + Clip 实现歌词扫光高亮效果

1. 常见歌词高亮的痛点，以及 HLSL + Clip 这套组合的思路

先说我为什么会折腾这个。做桌面歌词播放器的时候，最常用的高亮方案无非两种：一是给当前行换一个 Foreground，用前景色做颜色区分；二是叠两层 TextBlock，上面那层用 LinearGradientBrush 或者 OpacityMask 配合动画，模拟从左往右的扫描效果。做简单 Demo 的时候这两种都够用，但放到真正追求观感的场景里，问题就暴露了：颜色跳变太生硬，扫描边界是一条笔直的硬边，完全没有“光”的感觉。你要的是那种歌词被一束光扫过、边缘带一点光晕、亮度随距离逐渐衰减的效果，这已经超出普通画刷能描述的范围了，得让 GPU 参与逐像素计算。

于是我把目标拆成两个独立问题。第一个问题是“哪些区域是已唱区域”，这属于几何裁剪问题，WPF 自带Clip属性就能解决，用 RectangleGeometry 按进度裁掉高亮层即可；第二个问题是“已唱区域里光怎么分布”，这属于光学效果问题，纯粹用几何图形很难模拟出柔和衰减的光照，所以用 HLSL 写一个像素着色器，让每个像素根据它与光束中心的距离自行决定亮度。两个问题分开解决，再合成到一起，就是我标题里说的 HLSL + Clip 组合。

这个方案适合谁？如果你已经在用 WPF 做歌词类、字幕类、音视频播放器相关的界面，并且想让高亮效果从“变色”升级到“光照”，这篇文章可以直接照着抄。如果你只是偶尔做个小工具，没有 GPU 硬件加速的强需求，那普通颜色变化就够了，没必要上着色器。但你要是已经走到“我怎么才能做出那种扫光感”这一步，这篇大概率能给你省两天弯路。

需要先说明一点：WPF 的 ShaderEffect 走的是 DirectX 像素着色器管线，HLSL 版本大概在 2.0/3.0 的范围内，能力比现代游戏引擎里的 Shader Model 5/6 弱不少，但它应付这种 2D 歌词光效绰绰有余。后文所有代码我都按 ps_2_0 来写，这是 WPF 里兼容性最好、踩坑最少的一条路。

2. 第一步：用 Clip 把「已唱区域」切成几何体

2.1 双图层结构：底灰字、亮字、裁剪层

先搭歌词一行的界面结构。每一行歌词我用三个视觉元素：最底下是原始歌词，灰色，不带任何效果，用来保证整行文字始终可见；上面叠一个高亮宿主 Grid，里面放同样文字的 TextBlock，但前景色是亮色，并且给它挂着色器；关键一点，高亮宿主的Clip绑定到播放进度。进度从 0 到 1，裁剪矩形的宽度就是实际宽度 × 进度，这样未唱到的部分被几何裁掉，已唱部分才能看到亮字。

XAML 大致长这样：

<DataTemplate DataType="{x:Type local:LyricLineVm}"> <Grid x:Name="LineRoot" Height="48"> <TextBlock Text="{Binding Text}" Foreground="#FF707070" FontSize="32" FontFamily="Microsoft YaHei UI"/> <Grid x:Name="HighlightHost"> <Grid.Clip> <MultiBinding Converter="{StaticResource ProgressRectConverter}"> <Binding ElementName="LineRoot" Path="ActualWidth"/> <Binding Path="Progress"/> </MultiBinding> </Grid.Clip> <TextBlock Text="{Binding Text}" Foreground="#FFFFFFFF" FontSize="32" FontFamily="Microsoft YaHei UI"> <TextBlock.Effect> <local:LightSweepEffect LightOriginU="{Binding Progress}" FalloffU="0.10" Boost="1.1"/> </TextBlock.Effect> </TextBlock> </Grid> </Grid> </DataTemplate>

注意我把 Effect 放在了高亮 TextBlock 上，Clip 放在了外层 HighlightHost 上。这样安排有个实际好处：祖先节点的 Clip 一定是在子节点的渲染和 Effect 全部执行完之后才起作用的，所以不用担心 WPF 是先裁剪再光照还是先光照再裁剪的问题，几何和光学两件事被彻底隔开了。

2.2 为什么这里要用 MultiBinding，而不是直接绑一个 Rect

Clip属性接收的是 Geometry，所以最直接的做法是给 ViewModel 里放一个 RectangleGeometry 属性，播放进度一变就更新它。但问题在于：裁剪宽度需要知道这一行歌词渲染后的实际像素宽度，而ActualWidth是布局完成之后才有的值。除非每行字数固定，否则 ViewModel 里根本没法提前算准。

我采用的方案是用IMultiValueConverter，把两个来源组合成一个矩形：一个是LineRoot的ActualWidth，一个是 ViewModel 里的Progress。转换器代码如下：

public class ProgressRectConverter : IMultiValueConverter { public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture) { if (values.Length < 2 || values[0] is not double width || values[1] is not double progress) { return RectangleGeometry.Empty; } double revealWidth = Math.Max(0, width * progress); return new RectangleGeometry(new Rect(0, 0, revealWidth, 512)); } public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture) { throw new NotSupportedException(); } }

Clip的几何对象本身不需要参与反向绑定，所以 ConvertBack 直接抛异常就行。高度我写死 512，因为实际裁剪区域只要覆盖歌词行高就够了，没有必要严格等于字体实际高度。这里有一个初学者常踩的坑：ActualWidth在元素尚未完成布局时是 0，如果 ViewModel 在窗口刚加载、数据还没绑定完时就开始更新 Progress，你会发现高亮层直接被裁掉了。解决方法是把进度更新的启动时机放到Loaded事件之后，或者在播放器切歌时先确认当前行已经完成布局再推进度。

2.3 如果要做逐字高亮，而不是整行扫描

上面这套按 0~1 的进度做整行扫描，适合大多数歌词 UI。但如果你做的是 ktv 那种逐字点亮，就不能简单拿进度去乘宽度了，因为每个字宽度不一样。我补充一个实用做法：用FormattedText的MeasureText预先计算每个字符的累计像素宽度，然后把播放进度映射成字符序号和字内偏移。比如某行有 8 个字，进度到 30% 且落在第 4 个字中间，就先把前 3 个字完整裁出来，第 4 个字按它在整行宽度里的占比裁一半。这样 Clip 依然只负责几何裁剪，光效部分完全不用改，只是计算裁剪宽度的逻辑从width * progress变成查表 + 差值。

3. 第二步：写一个能跟着进度跑的光照着色器

3.1 着色器代码本身其实很短

HLSL 的像素着色器其实就是一个函数：传入 UV 坐标，返回颜色。WPF 里的 ShaderEffect 会把元素渲染结果作为一张纹理传进来，像素着色器对这个纹理逐像素采样。下面是我用的 LightSweep 着色器完整代码：

sampler2D implicitInput : register(s0); float LightOriginU : register(c0); float FalloffU : register(c1); float Boost : register(c2); float4 LightColor : register(c3); float4 main(float2 uv : TEXCOORD) : COLOR { float4 tex = tex2D(implicitInput, uv); float d = abs(uv.x - LightOriginU); float fall = 1.0 - smoothstep(0.0, 1.0, saturate(d / max(FalloffU, 0.0001))); fall = fall * fall; float3 lit = tex.rgb * (1.0 + Boost * fall); lit += LightColor.rgb * fall * 0.35; return float4(lit, tex.a); }

逐行解释一下。implicitInput是 WPF 固定提供的输入采样器，它采的就是应用了这个 Effect 的元素的渲染结果，对我们来说就是那层白色歌词文字。uv.x是 0 到 1 的横向位置，uv.y同理，所以我在着色器里用归一化坐标而不是像素坐标，这是为了适配不同宽度的歌词行。LightOriginU表示光束中心所在的横向位置，我把它绑定成进度Progress，这样光束中心永远和裁剪边界重合。FalloffU是光衰减半径，同样用归一化值，0.1 就代表大约 10% 的行宽作为过渡带。Boost控制整体照亮强度。LightColor是光晕的颜色，暖金色效果通常比纯白色更有“灯光感”。

关键逻辑就两行：先算当前像素到光束中心的距离 d，再用1 - smoothstep(0, 1, d / FalloffU)得到一个从中心向外衰减的系数 fall，最后把这个系数平方，让中心区域更亮、边缘衰减更柔和。结果是把原本的白色歌词亮度放大，同时额外混入一点 LightColor 的泛光。

3.2 为什么用 UV 空间而不是像素空间

这是我在试验中吃过亏才改过来的写法。最早我用的是像素坐标，LightOriginX 直接传界面上的 x 坐标，然后发现问题来了：WPF 的 ShaderEffect 拿到的是元素的局部空间，不同行的 TextBlock 宽度不一样，同样是 x=400，在一行 800px 宽的文字里和在另一行 1200px 宽的文字里，视觉效果完全不同。改成 UV 空间后，LightOriginU 永远和 Progress 一样是 0~1 的归一化值，光束中心自动对齐裁剪边界，换行、换字体、换字号都不需要重新调参。

3.3 编译.ps文件这一步卡了我很久

HLSL 源文件不能直接扔给 WPF 用，必须先用 DirectX 附带的fxc.exe编译成二进制字节码文件。命令如下：

fxc /T ps_2_0 /E main /Fo LightSweep.ps LightSweep.fx

/T ps_2_0指定目标着色器模型，/E main指定入口函数名，/Fo是输出文件。编译完成后，把LightSweep.ps加进项目，设置 Build Action 为 Resource。这个构建动作非常关键：如果设成 Content，运行时 pack URI 照样能写，但资源根本不在程序集里，你会发现效果完全没有，且没有异常可抓。设为 Resource 之后，C# 里加载的 URI 要写成：

new Uri("pack://application:,,,/LyricLighting;component/Shaders/LightSweep.ps")

其中LyricLighting是程序集名，component后面是资源在项目里的相对路径。

4. 第三步：把着色器接进 WPF：ShaderEffect 类的完整写法

4.1 自定义 Effect 类的骨架代码

WPF 不能直接把 .ps 文件贴到一个已有控件上，你得写一个继承ShaderEffect的类，把着色器的寄存器说明映射成依赖属性。我的实现如下：

public class LightSweepEffect : ShaderEffect { private static readonly PixelShader Shader = new PixelShader { UriSource = new Uri("pack://application:,,,/LyricLighting;component/Shaders/LightSweep.ps") }; public LightSweepEffect() { PixelShader = Shader; UpdateShaderValue(InputProperty); UpdateShaderValue(LightOriginUProperty); UpdateShaderValue(FalloffUProperty); UpdateShaderValue(BoostProperty); UpdateShaderValue(LightColorProperty); } public static readonly DependencyProperty InputProperty = RegisterPixelShaderSamplerProperty("Input", typeof(LightSweepEffect), 0); public static readonly DependencyProperty LightOriginUProperty = DependencyProperty.Register("LightOriginU", typeof(double), typeof(LightSweepEffect), new PropertyMetadata(0.0, PixelShaderConstantCallback(0))); public static readonly DependencyProperty FalloffUProperty = DependencyProperty.Register("FalloffU", typeof(double), typeof(LightSweepEffect), new PropertyMetadata(0.1, PixelShaderConstantCallback(1))); public static readonly DependencyProperty BoostProperty = DependencyProperty.Register("Boost", typeof(double), typeof(LightSweepEffect), new PropertyMetadata(1.0, PixelShaderConstantCallback(2))); public static readonly DependencyProperty LightColorProperty = DependencyProperty.Register("LightColor", typeof(Color), typeof(LightSweepEffect), new PropertyMetadata(Color.FromRgb(255, 220, 130), PixelShaderConstantCallback(3))); }

这段代码的映射关系非常重要。HLSL 里的register(c0)对应PixelShaderConstantCallback(0)，register(c1)对应PixelShaderConstantCallback(1)，依此类推。如果 C# 里把某两个参数的 Callback 索引写反了，效果不会报错，但参数顺序就会错乱。我建议在命名上保持一一对应，比如 HLSL 里用LightOriginU，C# 属性也叫LightOriginU，减少出错概率。

RegisterPixelShaderSamplerProperty的第一个参数是 WPF 层面对外暴露的属性名，第二个是类型，第三个是 sampler 寄存器索引 s0。因为只有一个输入采样器，索引填 0 即可。构造函数里必须调用一次UpdateShaderValue，否则属性能绑定上但 initial value 不会下发到着色器，第一次渲染可能看到的是默认寄存器内容。

4.2 在 DataTemplate 里绑定 Effect 属性

XAML 用法我在第 2 节已经贴过，核心是给高亮 TextBlock 挂一个局部 Effect 实例：

<TextBlock.Effect> <local:LightSweepEffect LightOriginU="{Binding Progress}" FalloffU="0.10" Boost="1.1" LightColor="#FFFFDC82"/> </TextBlock.Effect>

这里要特别提醒一个 WPF 的 Freezable 问题。ShaderEffect本身继承自Freezable，如果你把 Effect 实例放在资源里，比如<Window.Resources><local:LightSweepEffect x:Key="SharedEffect"/></Window.Resources>，然后多个控件共享一个实例，这个实例一旦被 Freeze，它的依赖属性就不能再通过 Binding 动态更新了。症状表现为：绑定了 Progress 但光照位置不动，界面看起来完全死掉。解决方式有两个：一是像我这样在 DataTemplate 里每次实例化一个独立的 Effect 对象；二是如果确需共享，就不要对参数做动态绑定，只在代码里一次性赋值。我在做多行歌词列表时一直用前者，每行一个效果实例，隔离干净，也不会互相污染参数。

5. 光照与裁剪怎么配合：渲染层级与参数绑定的关键顺序

5.1 最终渲染层级

把完整结构再画一遍：

LineRoot Grid ├── BaseText（灰色歌词，无效果） └── HighlightHost Grid（Clip = 进度矩形） └── BrightText（白色歌词，LightSweepEffect）

实际运行时，WPF 会先把 BrightText 连同它的 ShaderEffect 一起渲染到一张离屏纹理上，然后 HighlightHost 的 Clip 再对这个纹理做裁剪，最后把裁剪结果和 BaseText 合成。这个顺序意味着：光照计算发生在几何裁剪之前，但你看不到被剪掉区域的光，因为那些像素已经被裁掉了。两者职责互补——Clip 决定曝光区域，着色器决定曝光区域内的光照分布。

有一点值得一提：因为 BaseText 没有挂任何 Effect，它的颜色是普通 RenderOptions 路径渲染出来的，和挂着色器的 BrightText 相比，文字清晰度会更好，尤其在小字号下不会损失边缘锐度。这也算一个隐性收益：重要的底字保持不变，只有高亮层去承担模糊和光晕。

5.2 参数怎么联动：让光束中心追着裁剪边界跑

Clip 的宽度是ActualWidth * Progress，裁剪边界在横向的 UV 位置就是Progress，所以LightOriginU直接绑 Progress，光束中心就自动贴在裁剪边界上。当 Progress 从 0 增加到 1 时，会发生这样的事：裁剪边界从行首移动到行尾，同时光束中心也从行首移动到行尾，亮字区域越来越大，光束永远在边界处维持一个“扫过头灯”的高亮亮感。如果去掉绑定，光束中心停在中间，你会看到未唱部分也被照亮了，整体观感就不对了。

我实际测试下来的观感是：FalloffU 不要太大，0.06~0.12 之间最耐看。太大时整个行都处于强光下，光晕失去方向意义；太小时光带非常窄，扫的时候容易让边缘出现明显锯齿感，反而不柔和。Boost 在 1.0~1.5 区间内最好，超过 2.0 白色字体会过曝到完全看不出笔画结构。

5.3 如果整个歌词面板要共用一个光，而不是逐行各自扫

我上面的方案是每一行歌词都有自己独立的光束，光束中心始终是该行的裁剪边界。这是“卡拉OK逐行”风格。但如果你想要的是“一束光扫过整个屏幕，所有歌词行同时被一束光从左边扫到右边”的现场感，思路就不同了。那样的话应该把 ShaderEffect 挂在整个歌词面板（比如 ScrollViewer 或 ItemsControl）的外层，而不是每一行，然后用一个全局进度来驱动LightOriginU。问题是外层面板的裁剪会一次性裁掉所有行，无法区分每行各自的已唱区域，所以这种全局光方案通常需要再给每行加一个独立的 OpacityMask 或者沿用 Clip，层级复杂度会上一个台阶。我个人的建议是：如果只是做播放器歌词，逐行的方案更好实现也更好看；如果是做大型活动字幕墙，再考虑全局光。

6. 实测调参、性能观察与几个容易翻车的细节

6.1 最让我头疼的三个问题

第一个是.ps文件加载失败但不报错。ShaderEffect 加载资源如果失败，最常见的结果是整个元素直接不渲染，连异常都不一定抛。当时我检查半天发现是 Build Action 设成了 Content，改成 Resource 后立刻正常。第二个是 Freezable 共享导致的参数不可变，我在第 4 节已经详细说过。第三个是进度更新时机，Clip 绑定到 ActualWidth 后，如果在元素还没有布局完成时就去改 Progress，宽度为 0，高亮永远是空的。所以我后来把所有进度推动都放在Loaded之后，并且绑定用Mode=OneWay，避免不必要的回写往返。

6.2 性能：别让每一行都常驻 ShaderEffect

每一层挂 Effect，WPF 就要把该元素渲染到一张离屏纹理上，再做一遍着色器处理，这是有 GPU 开销的。歌词列表如果一屏显示 10 行，10 行都挂 Effect，在低端核显上能明显感觉到帧率下降。优化思路有两条。一条是只给当前播放行和它的上一行/下一行挂 Effect，其他行用普通白字或者纯色高亮，反正远处行的光效用户也注意不到。另一条是给非当前行开启CacheMode="BitmapCache"，把静态渲染缓存成位图，避免每次帧循环都重复执行 ShaderEffect。我实测过，一屏 7 行歌词中只让当前行效果全开，其他行缓存，帧率能保持住，观感几乎不变。

6.3 调参参考表

文字层主体建议保持不用 Effect，否则小字号下边缘会发虚。高亮层用白色，再让着色器去加光晕颜色，比直接给前景设金黄色更自然。

6.4 没有独立显卡时怎么办

WPF 的 ShaderEffect 依赖硬件加速，如果目标机器渲染能力不足，效果会被静默跳过。我的做法是在启动时检查RenderCapability.Tier，小于 2 时切换成纯色高亮模式，用 Foreground 变色和简单的 Clip 扫描顶上。判断代码就一句：

if (RenderCapability.Tier < 2) { // 切到无着色器模式 }

这首歌显示、下首歌显示这种场景，用户要的是稳定不崩，干净利落地降级比特效华丽但掉帧更合理。

最后补一个我在实际项目里养成的小习惯：不要让进度数据在 ViewModel 里裸奔，建议封装一个UpdatePlayProgress(TimeSpan position, TimeSpan duration)方法，内部做 clamp 和字符映射，外部只管调一次。这样 Clip 和着色器拿到的永远是 0 到 1 的干净值，切歌、拖动进度条、暂停续播都不会出现进度回跳导致的高亮闪烁。