WPF BitmapCache 源码解构（四）：缓存失效、阈值控制与显存管理

系列：WPF BitmapCache 源码解构 · 第四篇作者：JusterZhu

概要

关键概念区分：RenderOptions.CacheInvalidationThresholdMinimum / Maximum 是 TileBrush（DrawingBrush、VisualBrush）的缓存阈值属性，控制基于渲染尺寸比值的重生成时机，自 .NET 3.0 即存在。BitmapCache（UIElement.CacheMode）使用子树内容变化驱动的失效逻辑，不通过这两个阈值属性控制。两类缓存的底层失效检测链路（托管 → DUCE → MIL）高度重叠，但控制入口和触发条件完全不同。本文覆盖两者并在每处指明作用对象。

本文聚焦 BitmapCache 生命周期中三个最容易出问题的环节：缓存失效触发条件与传播链路（从 UIElement.InvalidateVisual() 到 MIL 层纹理重建的五类触发条件）、阈值控制机制（区分 TileBrush 缓存与 BitmapCache 自身失效，深入 DUCE 序列化与 MIL 层 C++ 源码路径）、GPU 显存管理（纹理尺寸公式、D3DPOOL_DEFAULT 纹理生命周期、GDI 句柄耗尽陷阱）。最后提供软件渲染回退分析、调试工具使用指南和一套可直接运行的性能测试代码。

一、缓存失效机制

1.1 失效触发条件的完整列表

BitmapCache 不是"一次渲染、永久有效"的静态快照。当特定条件满足时，WPF 的渲染管线必须丢弃旧缓存、重新执行 Render 遍历并生成新的 GPU 纹理。以下是完整的触发条件分类，每类均标注了对应的源码方法和关键文件：

（A）布局变化：Arrange 产生新的 finalSize

触发条件：当 UIElement 的 Arrange 阶段产出与缓存时不同的 finalSize，即元素的实际渲染尺寸发生变化（窗口缩放、父容器布局改变、显式设置 Width/Height 等）。

源码路径：

• UIElement.Arrange(Rect finalRect) → 内部调用 ArrangeCore → 若 finalSize != previousFinalSize，则设置 _isArrangeDirty = false 但标记渲染脏
• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows/UIElement.cs
• FrameworkElement.ArrangeCore 中比较 RenderSize，变化时调用 InvalidateVisual()

失效传播：布局变化 → InvalidateVisual() → _isRenderDirty = true → 下一个 Render 帧时 DUCE 通道通知 MIL 层 BitmapCache 节点脏 → 纹理重建

（B）渲染变化：子元素 RenderTransform / Clip 变化

触发条件：缓存的 UIElement 子树内任何子元素的以下属性发生变化：

• RenderTransform 或其子属性（ScaleTransform.ScaleX 等）
• Clip 几何形状
• 子元素的视觉内容（如 TextBlock.Text 变化触发重新排版和渲染）

源码路径：

• UIElement.RenderTransformProperty 的 PropertyChangedCallback → OnRenderTransformChanged → 标记 _isTransformDirty = true
• UIElement.ClipProperty 的属性变更回调 → InvalidateVisual()
• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows/UIElement.cs

失效传播：子元素属性变化 → 父链向上传播 dirty flag → 最终到达缓存节点 → MIL 层缓存脏标记置位

（C）视觉效果变化：Opacity / Effect / OpacityMask 变化

触发条件：缓存元素自身或其子树内元素的以下属性变化：

• Opacity（透明度）
• Effect（如 DropShadowEffect、BlurEffect）
• OpacityMask
• BitmapEffect（已废弃但仍存在于旧代码中）

源码路径：

• UIElement.OpacityProperty 的 PropertyChangedCallback → OnOpacityChanged → InvalidateVisual()
• UIElement.EffectProperty → OnEffectChanged → InvalidateVisual()
• UIElement.OpacityMaskProperty → OnOpacityMaskChanged → InvalidateVisual()
• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows/UIElement.cs

失效传播：属性变更回调 → InvalidateVisual() → dirty flag → DUCE → MIL 缓存重建

（D）BitmapCache 自身属性变化：RenderAtScale / SnapsToDevicePixels / EnableClearType

触发条件：修改缓存的 BitmapCache 实例上的以下属性：

• RenderAtScale：缩放比例变化 → 纹理尺寸变化 → 必须重建
• EnableClearType：ClearType 开关 → 像素格式或渲染路径变化 → 必须重建
• SnapsToDevicePixels：像素对齐策略变化 → 必须重建

源码路径：

• BitmapCache.RenderAtScaleProperty 的 PropertyChangedCallback → OnRenderAtScaleChanged → 内部调用 DUCE 资源更新
• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows\Media\BitmapCache.cs

失效传播：BitmapCache 实现了 DUCE.IResource → 属性变更时调用 InvalidateResource() → 注册到 MediaContext.ResourcesUpdated → 下一帧通过 UpdateResource(channel, ...) 序列化新属性 → MIL 层接收更新并触发纹理重建

（E）显式失效：InvalidateVisual / InvalidateArrange

触发条件：开发者代码显式调用：

• element.InvalidateVisual()：强制重新渲染
• element.InvalidateArrange()：强制重新布局 → 间接触发重新渲染

源码路径：

• UIElement.InvalidateVisual() → 设置内部 _isRenderDirty = true → MediaContext 收集脏 Visual
• UIElement.InvalidateArrange() → 设置 _isArrangeDirty = true → 下一布局遍触发 → 间接触发渲染
• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows/UIElement.cs

1.2 失效检测的代码路径

失效检测贯穿三层架构：托管 Visual 层（C#）→ DUCE 通道（CLR-to-Native Bridge）→ MIL 合成器层（C++）。以下是完整的端到端流程。

第一层：UIElement 标记 Dirty（C# 托管层）

Application Code    |    vUIElement.InvalidateVisual()                          // PresentationCore/UIElement.cs    |    ├── 检查 IsVisualChildrenIterationInProgress    |   （防止遍历期间自递归，违反时抛出异常）    |    ├── 设置 _isRenderDirty = true                     // 内部标志位    |    └── 注册到 MediaContext.CurrentMediaContext        .InvalidatedVisuals 集合

关键代码结构（基于公开架构的简化表示，非实际源码）：

// UIElement.cs — 简化示意publicvoidInvalidateVisual(){if (IsVisualChildrenIterationInProgress)thrownew InvalidOperationException(SR.Get(SRID.CannotModifyVisualChildren));    _isRenderDirty = true;    MediaContext.CurrentMediaContext.NotifyVisualDirty(this);}

此外，Visual 基类维护以下关键标志位：

• _isRenderDirty：视觉内容需要重新渲染
• _isArrangeDirty：布局需要重新计算
• _isMeasureDirty：测量需要重新计算
• _isTransformDirty：变换矩阵已变化
• _isVisualChildrenIterationInProgress：防止重入的保护标志

第二层：DUCE 通道传递无效化通知

[Render Frame Boundary]    |    vMediaContext.Render()                                // PresentationCore    |    ├── 遍历 InvalidatedVisuals 集合    |    ├── 对每个 Dirty Visual，调用其    |   DUCE.IResource.UpdateResource(channel, ...)    |    ├── UpdateResource 内部：    |   ├── 获取 CompositionEngineLock（线程安全）    |   ├── 打包 MILCMD_VISUAL_INVALIDATE 结构体    |   │   （包含视觉节点的句柄和新状态）    |   └── channel.SendCommand(pCommandData, size)    |       （内存直通，非 IPC/Socket）    |    └── 传递至 wpfgfx_cor3.dll (milcore)

DUCE 通道的核心抽象——DUCE.Channel 和 DUCE.IResource——位于：

• 托管层文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows\Media\Composition/DUCE.cs

SendCommand 不是命名管道或 Socket 通信，而是内存直通（Direct Memory Communication）。托管层将序列化后的 MIL 命令结构体直接写入 CLR 和原生 C++ 层共享的内存区域，零拷贝传递。

当启用 BitmapCache 的 UIElement 的子元素发生变化时，DUCE 通道传递的命令类型会包含缓存脏标记，告知 MIL 合成器当前缓存已失效。这个过程是增量式的——只有真正被标记为 dirty 的节点才会产生 DUCE 流量。

第三层：MIL 层判断缓存脏了（C++ 原生层）

MIL Compositor Thread                               // wpfgfx_cor3.dll    |    v接收 DUCE 命令 → 更新内部合成节点树    |    ├── BitmapCache 代理节点检测到子树结构变化    |    ├── 比较当前属性（scale, transform, render bounds）    |   与上次缓存时的快照值    |    ├── 若任一项不匹配 → 设置 CacheDirtyFlag = true    |    ├── 下次 VSync 时：    |   ├── 释放旧 D3D9 纹理    |   ├── 创建新渲染目标纹理    |   ├── 重新渲染子树到新纹理    |   └── 将新纹理绑定到缓存节点    |    └── 通过 DWM Present 到屏幕

MIL 合成器内部维护着每个 BitmapCache 节点的"已知良好状态"快照。当从 DUCE 通道收到新的子树状态时，它会逐项比较：

1. 子节点集合是否有增删（结构变化 → 缓存脏）
2. 每个子节点的属性是否与快照一致（内容变化 → 缓存脏）
3. 缓存节点自身的配置（RenderAtScale 等）是否变化（配置变化 → 缓存脏）

三者有一项不匹配，缓存即被判定为 dirty 并触发重建。

1.3 脏矩形累加机制

WPF 的 dirty rect 系统在 MIL 层中处理多次小范围失效时采用了智能的合并与裁剪策略。基于 WPF 公开架构推理（wpfgfx_cor3.dll 内的合成器负责脏区域管理）：

1. 累加：当多次 InvalidateVisual() 在单个帧内发生时，每次调用产生的脏矩形被添加到内部列表中
2. 去重与合并：新增脏矩形首先检查是否已被现有矩形包含（是则忽略），当矩形数量超过内部上限常量时，所有矩形合并为一个大的包围盒（bounding box），避免列表膨胀
3. 帧边界结算：VSync 到来时，合成器线程遍历所有脏矩形，仅对脏区域执行重渲染，非脏区域直接从上一帧的前缓冲区拷贝

推理依据：以上流程是保留模式渲染引擎中 dirty rect 管理的通用模式。WPF 的脏区域行为可通过 Perforator 工具的 "Dirty Region Overlay" 叠加层直接观察，但具体的内部常量名和方法签名为 MIL 实现细节。

后缓冲区→前缓冲区拷贝优化

这一步常被误解。它只优化后缓冲区→前缓冲区的像素拷贝量，并不改变渲染行为本身：

渲染帧开始    |    v收集阶段（Collect Phase）    |    ├── CopyForwardDirtyRects()    |   ├── 遍历所有脏矩形    |   ├── 通过 IWICBitmapSource::CopyPixels()    |   |   将后缓存的脏区域像素拷贝到前缓存    |   └── 非脏区域不做拷贝（零开销）    |    ├── 渲染阶段（Render Phase）    |   └── 整个图片作为**整体纹理**提交到 D3D 管线    |       （DirtyRect 在此阶段不产生粒度优化）    |    └── 呈现阶段（Present Phase）

结论：多次小范围失效不会触发多次完整的缓存重建。在单个渲染帧内，所有失效被合并处理后，BitmapCache 纹理在帧结束时完成一次重建。但需注意，缓存纹理的重建是全量的——即使只有 10×10 像素的区域脏了，整个缓存纹理（可能 2048×2048）都会被重新渲染。

脏矩形阈值与 DisableDirtyRegionSupport

MIL 合成器有一个内部开关 g_fDirtyRegion_Enabled（位于 wpfgfx.dll 中）。当通过注册表或 WPF 内部调试接口将其禁用（设为 false）时：

• 合成器停止追踪脏矩形
• 每帧强制全窗口重渲染
• BitmapCache 的行为退化为"每帧重建缓存"

这个开关可以通过以下方式控制：

• 注册表：HKCU\SOFTWARE\Microsoft\Avalon.Graphics\EnableDebugControl = 1（需管理员权限创建），然后设置 DisableDirtyRegionSupport = 1
• 进程调试接口：wpfgfx_v0400-<PID> 进程中包含 MediaControl 结构体，其 DisableDirtyRegionSupport 字段可通过 WPF 内部调试接口调整

注意：直接修改进程内部状态属于高级调试操作，在操作不当时可能导致目标 WPF 进程不稳定。此方法仅供调试诊断使用，不推荐在生产环境中执行。建议优先使用注册表方式。

这是调试 BitmapCache 冻结（Issue #8919）的关键技术手段之一。

1.4 与普通渲染的 Dirty Rect 传播差异

普通的（无 BitmapCache 的）WPF 渲染与启用了 BitmapCache 的渲染在 dirty rect 传播上存在根本性差异：

关键理解：BitmapCache 的本质是用空间（显存）换时间（重渲染开销）。当子树内容频繁变化时，缓存纹理的全量重建开销可能超过无缓存时的增量渲染。这就是为什么"动画频繁但范围小"的场景使用 BitmapCache 往往得不偿失。

传播路径差异的可视化：

无缓存：  子元素 TextBlock.Text 变化    → TextBlock._isRenderDirty = true    → StackPanel 标记局部脏区域    → Grid 标记局部脏区域    → Window 标记局部脏区域    → 下一帧：仅重绘受影响的像素区域BitmapCache：  子元素 TextBlock.Text 变化    → TextBlock._isRenderDirty = true    → 脏标记传播到缓存节点，被"吸收"    → 缓存节点标记 CacheDirty = true    → Window 不感知内部变化（缓存节点对外"干净"）    → 下一帧：整张纹理重建 + Window 仅做一次纹理 Blit

二、CacheInvalidationThreshold 机制

2.1 概念区分：TileBrush 缓存 vs BitmapCache

在深入阈值机制之前，必须澄清一个极易混淆的关键概念：

RenderOptions.CacheInvalidationThresholdMinimum 和 RenderOptions.CacheInvalidationThresholdMaximum 是 TileBrush（DrawingBrush、VisualBrush）的缓存控制属性，而非 BitmapCache（UIElement.CacheMode）的直接控制属性。

两者虽然都涉及"缓存"和"失效"，但作用对象和机制完全不同：

两种缓存的异同：

• 相同点：都是将渲染结果缓存为位图纹理、都在 GPU 端存储、都通过 DUCE 通道与 MIL 层通信、都有基于"变化"的自动失效机制。
• 不同点：
• TileBrush 缓存由 CachingHint + 阈值属性控制，失效判断基于"渲染尺寸相对于缓存尺寸的比例"。
• BitmapCache 由 CacheMode 属性激活，失效判断基于"子树内容/结构/属性是否变化"。
• TileBrush 缓存主要用于 VisualBrush 的缩放场景（如缩略图、实时预览），BitmapCache 用于优化复杂子树的渲染。

本文将两者都覆盖——因为它们的底层失效检测链路（托管→DUCE→MIL）高度重叠，且在实际项目中经常同时使用。文中将明确指出每种描述适用的是 TileBrush 缓存还是 BitmapCache。

2.2 CacheInvalidationThresholdMinimum 与 Maximum

这两个附加属性定义在 System.Windows.Media.RenderOptions 静态类中：

// 源码文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows\Media\RenderOptions.cspublicstaticreadonly DependencyProperty CacheInvalidationThresholdMinimumProperty =    DependencyProperty.RegisterAttached("CacheInvalidationThresholdMinimum",typeof(double),typeof(RenderOptions),new FrameworkPropertyMetadata(0.5));  // 默认值 0.5publicstaticreadonly DependencyProperty CacheInvalidationThresholdMaximumProperty =    DependencyProperty.RegisterAttached("CacheInvalidationThresholdMaximum",typeof(double),typeof(RenderOptions),new FrameworkPropertyMetadata(2.0));  // 默认值 2.0

CacheInvalidationThresholdMinimum（默认 0.5）的含义

语义：当 TileBrush 的渲染尺寸缩小到当前缓存尺寸的 50% 以下时，触发缓存重生成。

例如：

• 当前缓存了 200×200 像素的 VisualBrush 内容
• 用户将画布缩小，VisualBrush 需要渲染为 80×80 像素
• 缩小比例：80/200 = 0.4 < 0.5 → 触发缓存重生成
• 新缓存尺寸：80×80，新缓存中的图像比旧缓存放大到 80×80 更清晰

如果阈值设为 0.5，缩放到 110×110（比例 0.55 > 0.5）则不会触发重生成——旧的 200×200 纹理将继续使用，只是 GPU 采样时做了缩小过滤。

CacheInvalidationThresholdMaximum（默认 2.0）的含义

语义：当 TileBrush 的渲染尺寸放大到当前缓存尺寸的 200% 以上时，触发缓存重生成。

例如：

• 当前缓存了 200×200 像素的 VisualBrush 内容
• 用户将画布放大，VisualBrush 需要渲染为 500×500 像素
• 放大比例：500/200 = 2.5 > 2.0 → 触发缓存重生成
• 新缓存尺寸：500×500，内容清晰锐利

如果阈值设为 2.0，放大到 350×350（比例 1.75 < 2.0）则不会触发重生成——旧的 200×200 纹理将被 GPU 放大到 350×350，产生轻微模糊但节省了重渲染开销。

比值计算公式

实际渲染尺寸 / 当前缓存尺寸    < CacheInvalidationThresholdMinimum  → 触发重生成（缩小越界）    > CacheInvalidationThresholdMaximum  → 触发重生成（放大越界）    在 [Minimum, Maximum] 区间内       → 保持当前缓存，GPU 缩放复用

2.3 计算单位与坐标空间

设备无关像素（DIP） vs 物理像素

CacheInvalidationThresholdMinimum 和 CacheInvalidationThresholdMaximum 是无量纲比值（ratio），不是像素单位。它们比较的是"渲染尺寸与缓存尺寸的比率"，因此天然独立于 DPI 或像素单位。

但是，**决定"渲染尺寸"和"缓存尺寸"**的实际计算涉及 DPI 和 RenderAtScale（仅 BitmapCache）的参与：

• TileBrush 缓存：缓存尺寸 = 元素的实际渲染像素尺寸 × DPI 缩放因子
• BitmapCache：纹理尺寸 = 元素布局尺寸 × RenderAtScale × DPI 缩放因子

以 BitmapCache 为例，一个 200×200 DIP 的元素在 150% DPI 显示器上，RenderAtScale = 2.0：

纹理宽度 = 200 DIP × 2.0 (RenderAtScale) × 1.5 (DPI) = 600 物理像素纹理内存 = 600 × 600 × 4 = 1,440,000 字节 ≈ 1.37 MB

是否受 RenderAtScale 影响

对于 TileBrush 缓存：不受 BitmapCache.RenderAtScale 影响（那是另一个缓存系统）。但受到 VisualBrush 自身的 Viewbox 和 Viewport 设置影响，这些决定了"渲染尺寸"。

对于 BitmapCache：RenderAtScale 通过决定缓存纹理的基础尺寸，间接触发了失效判断——当 RenderAtScale 自身变化时，作为属性变化触发条件直接重建缓存，不经过阈值比较路径。

2.4 源码路径全链路追踪

Step 1：附加属性的定义（托管 C#）

• 文件：src\Microsoft.DotNet.Wpf\src\PresentationCore\System/Windows\Media\RenderOptions.cs
• 关键代码：依赖属性注册（见 2.2 节）、GetCacheInvalidationThresholdMinimum(DependencyObject) / SetCacheInvalidationThresholdMinimum(DependencyObject, double) 访问器、[AttachedPropertyBrowsableForType(typeof(TileBrush))] 特性标注（设计师仅在 TileBrush 类型上显示该属性）

Step 2：TileBrush 检测属性变化（托管 C#）

当 CacheInvalidationThresholdMinimum 或 CacheInvalidationThresholdMaximum 的值在 TileBrush 上变化时：

1. TileBrush（实现 DUCE.IResource）的依赖属性系统检测到变化
2. 调用 InvalidateResource() 注册到 MediaContext.ResourcesUpdated 事件
3. 在下一个渲染帧，UpdateResource(channel, ...) 被调用

Step 3：DUCE 序列化（托管 C# → 原生）

• 文件：TileBrush 的 UpdateResourceCore 方法
• 操作：将新的阈值打包到 MILCMD_TILEBRUSH_UPDATE（名称推断自 DUCE 命令命名惯例）或类似结构中
• 发送：channel.SendCommand((byte*)&data, sizeof(data))

Step 4：MIL 层阈值比较（C++ 原生）

MIL 合成器线程接收到更新后的阈值：

1. 更新内部 TileBrush 代理对象的阈值字段
2. 每次 TileBrush 被采样时（GPU 绑定其缓存纹理前），比较当前渲染尺寸与缓存尺寸的比值
3. 若超出 [ThresholdMinimum, ThresholdMaximum] 范围 → 标记缓存脏 → 触发重生成
4. 在区间内 → 直接绑定当前纹理，GPU 完成缩放采样

推理依据：

• TileBrush 的缓存位于 MIL 层（WpfGfx/core/ 目录）
• 阈值比较属于渲染资源在帧渲染前的 PreRender 或缓存有效性校验阶段

注意：以上为基于渲染管线架构的推理，具体类名和方法签名以仓库实际源码为准。

2.5 典型调参场景

场景一：动画频繁但更新范围小 → 调高 Minimum

背景：一个 VisualBrush 用于实时缩略图预览，用户在缩小时频繁拖拽缩放滑块。

问题：默认 CacheInvalidationThresholdMinimum = 0.5 意味着每次缩小超过 50% 就重建缓存。在连续缩放动画中，这会产生数十次缓存重建，每次都要重新渲染整个 VisualBrush 的源 Visual 树。

调参策略：

<VisualBrush    RenderOptions.CachingHint="Cache"    RenderOptions.CacheInvalidationThresholdMinimum="0.2"    RenderOptions.CacheInvalidationThresholdMaximum="5.0">    <!-- VisualBrush 内容 --></VisualBrush>

效果：阈值下限设为 0.2（缩小到 20% 才重建），上限设为 5.0（放大到 500% 才重建）。在 1×→3× 的缩放动画中，只需要 1 次重建（第一次超出阈值），而不是 N 次。代价是在 2×-5× 之间 GPU 做放大采样，视觉上略有模糊。

场景二：静态但偶尔大面积失效 → 调低 Maximum

背景：一个 DrawingBrush 用于绘制复杂的矢量地图背景，大部分时间静态，但偶尔（如用户切换图层）后整个地图内容完全变化。

问题：默认 CacheInvalidationThresholdMaximum = 2.0 在静态场景下无关紧要，但内容完全变化时需要立即重建缓存以达到最佳清晰度。

调参策略：

<DrawingBrush    RenderOptions.CachingHint="Cache"    RenderOptions.CacheInvalidationThresholdMinimum="0.8"    RenderOptions.CacheInvalidationThresholdMaximum="1.2">    <!-- DrawingBrush 内容 --></DrawingBrush>

效果：阈值范围收窄到 [0.8, 1.2]。渲染尺寸只要偏离缓存尺寸 20% 就触发重建，确保地图始终以接近原生分辨率渲染。对于静态为主的场景，缓存重建开销可接受。

场景三：BitmapCache 的 RenderAtScale 调优

对于 BitmapCache（注意这里用的是 RenderAtScale 而非阈值属性）：

背景：一个包含 50+ 控件的复杂 Dashboard 面板，在 200% DPI 显示器上使用 CacheMode="BitmapCache"。

问题：默认 RenderAtScale = 1.0 在 200% DPI 下产生的纹理是布局尺寸的 2×（来自 DPI 缩放），而非 4×。若面板同时被 ScaleTransform 放大 1.5×，GPU 会进一步放大采样，导致文本模糊。

调参策略：

<GridCacheMode="BitmapCache"><Grid.CacheMode><BitmapCacheRenderAtScale="3.0"EnableClearType="True" /></Grid.CacheMode><!-- 50+ 控件 --></Grid>

效果：纹理以 3× 布局尺寸渲染 → 在 200% DPI（2×）下，纹理像素密度为 3×/2× = 1.5× 原生 → 即使有 1.5× 的 ScaleTransform，GPU 仍是缩小采样而非放大采样 → 文本保持清晰。代价是显存占用增大到原来的 (3.0/1.0)² = 9 倍。

2.6 阈值设为 0 的特殊含义

对于 TileBrush 缓存的阈值属性，将 CacheInvalidationThresholdMinimum 或 CacheInvalidationThresholdMaximum 设为 0 具有特殊语义：

CacheInvalidationThresholdMinimum = 0

含义：永远不要因为缩小而延迟重绘。TileBrush 在任意缩小（渲染尺寸 < 缓存尺寸）时都立即重建缓存。

实际效果等同于：缩小时始终以当前渲染尺寸生成新缓存，始终获得最佳清晰度。

<VisualBrush    RenderOptions.CachingHint="Cache"    RenderOptions.CacheInvalidationThresholdMinimum="0">    <!-- 始终以最佳分辨率渲染 --></VisualBrush>

CacheInvalidationThresholdMaximum = 0

含义：永远不要因为放大而延迟重绘。TileBrush 在任意放大（渲染尺寸 > 缓存尺寸）时都立即重建缓存。

实际效果等同于：放大时始终以当前渲染尺寸生成新缓存，始终保持最佳清晰度。

<VisualBrush    RenderOptions.CachingHint="Cache"    RenderOptions.CacheInvalidationThresholdMaximum="0">    <!-- 放大时始终立即重建 --></VisualBrush>

两个都设为 0

含义等同于"始终立即重绘，永不复用缓存"——每次 TileBrush 的渲染尺寸与缓存尺寸不一致时都立即重建缓存。这实际上退化到了无缓存的行为（每次采样都重新渲染），但通过缓存机制间接执行，开销反而可能比不用缓存更大。

建议：仅在以下情况将阈值设为 0：

• 调试缓存行为，需要观察每次重生成
• 内容变化极其频繁且质量要求绝对最高
• GPU 缩放的质量不可接受（如医学影像、高精度图形）

对于生产环境的大多数场景，保留默认值（0.5 / 2.0）或适度调整即可。

2.7 BitmapCache 自身的失效逻辑

重申关键区分：BitmapCache（UIElement.CacheMode）不使用 CacheInvalidationThresholdMinimum 或 CacheInvalidationThresholdMaximum。

BitmapCache 的失效逻辑更简单直接——内容变化即失效：

BitmapCache 缓存纹理的生命周期：    |    ├── 创建：CacheMode 首次设为非 null BitmapCache    |    ├── 保持：子树无任何变化 → 纹理在多个帧间持续复用    |        祖先变换（TranslateTransform 等）不触发缓存重建    |        → 缓存纹理在 GPU 端通过纹理采样完成位移/旋转    |    ├── 失效：子树任一元素发生 §1.1 中列举的任何变化    |        → 缓存脏 → 下一帧重建纹理    |    └── 销毁：CacheMode = null 或元素脱离 VisualTree

BitmapCache 与 TileBrush 缓存的协同： 当 BitmapCache 子树内包含 VisualBrush（且该 VisualBrush 配置了 CachingHint="Cache" 和阈值）时，两种缓存同时生效：

• 外层：BitmapCache 缓存整个子树为一张 GPU 纹理
• 内层：VisualBrush 内部缓存其源 Visual 为独立纹理

当子树的 VisualBrush 内容变化时：

1. VisualBrush 缓存首先被标记脏（根据其阈值）
2. VisualBrush 的 TileBrush 缓存重建
3. 重建后的 VisualBrush 触发了外层 BitmapCache 的子树内容变化检测
4. 外层 BitmapCache 也被标记脏并重建

这就是缓存的层叠失效（Cascading Invalidation）——内层缓存的任何变化最终会穿透到外层。在设计深层 UI 结构时需注意这一点：过多的嵌套缓存可能导致"改一行文本触发 N 层纹理重建"的雪崩效应。

三、GPU 显存管理

3.1 纹理存储位置：托管堆 vs 非托管显存

BitmapCache 创建的 D3D9 纹理在内存中有两个"影子"：

关键理解：BitmapCache 托管对象只是一个"遥控器"，它的 DUCE.MultiChannelResource._duceResource 字段存储着一个不透明的 ResourceHandle（本质是整数句柄），指向 wpfgfx_cor3.dll 中真正持有的 D3D9 纹理。GC 回收 BitmapCache 对象时，其 Finalizer 会通过 DUCE 通道通知 MIL 层释放对应的原生纹理。

WPF 使用的 D3D9 内存池（D3DPOOL）分为两类，取决于系统安装的显示驱动模型：

• WDDM（Windows Display Driver Model，Vista 起引入的现代驱动模型）：D3DPOOL_DEFAULT——纹理完全驻留在 GPU 显存中，CPU 无法直接访问。这是默认且最优的路径。WDDM 下的显存由 OS 虚拟化管理，多个进程可以共享物理 VRAM。
• XPDM（Windows XP Display Driver Model，旧版驱动模型）：D3DPOOL_MANAGED——GPU 显存中一份副本 + 系统内存中一份备份，D3D9 Runtime 自动同步两端。在 Device Lost（GPU 设备丢失）发生时，Runtime 能用备份自动恢复纹理——但代价是相当于"每张纹理存了两遍"。
• 软件渲染回退：不使用 D3D9 纹理——见 §3.5。

这个存储策略意味着：

1. 你不能用 new 或 malloc 的思维理解 BitmapCache 的内存消耗——实际显存占用通过 GPU-Z 等工具观察，不在 .NET 内存分析的视野内。
2. 托管堆上的 BitmapCache 对象可能只有 ~200 字节，但它"遥控"的 D3D9 纹理可能占用 30+ MB VRAM。
3. CLR GC 不直接管理 VRAM——即使 BitmapCache 被 Gen2 回收，VRAM 释放也依赖于 Finalizer 线程的不确定调度。

3.2 纹理尺寸计算公式与实际显存估算

通用公式

texture_width_px  = element_W_dip × RenderAtScale × DpiScaleXtexture_height_px = element_H_dip × RenderAtScale × DpiScaleYtexture_bytes      = texture_width_px × texture_height_px × 4

其中：

• element_W_dip / element_H_dip：UIElement 经过 Arrange 后的 RenderSize（设备无关像素）
• RenderAtScale：BitmapCache.RenderAtScale，默认 1.0
• DpiScaleX / DpiScaleY：显示器 DPI 缩放因子（96 DPI = 1.0，144 DPI = 1.5，192 DPI = 2.0）
• × 4：每个像素 4 字节（BGRA32 / PixelFormats.Pbgra32，Premultiplied Alpha）

实际显存占用速查表

上表最后一行值得警惕：RenderAtScale = 3.0 在 200% DPI 下产生 11K 纹理，285 MB VRAM。单个 BitmapCache 就可能触发 VRAM 预算溢出并迫使 WPF 回退到软件渲染。

最大纹理尺寸限制

当 BitmapCache 需要的纹理超过硬件支持时，WPF 不会抛异常，而是静默降采样到最大支持尺寸，导致渲染结果出现模糊/"JPEG 感"。这是一种静默降级，开发者可能需要借助调试工具才能发现。

3.3 纹理复用：共享还是独立

直接答案：WPF 不提供 BitmapCache 纹理的自动共享/复用机制。每个 CacheMode = new BitmapCache(...) 的 UIElement 会创建独立的 D3D9 纹理。

但这不意味着纹理无法共享。WPF 提供了 BitmapCacheBrush 作为显式的纹理共享机制：

<!-- 源：一个复杂的可视化树，使用 BitmapCache --><Gridx:Name="ComplexPanel"><Grid.CacheMode><BitmapCacheRenderAtScale="1.0" /></Grid.CacheMode><!-- 大量复杂元素 --></Grid><!-- 多个消费者共享同一张缓存纹理 --><RectangleFill="{Binding Source={StaticResource CacheBrush}}" /><EllipseFill="{Binding Source={StaticResource CacheBrush}}" />

BitmapCacheBrush 持有对 MIL 层中特定缓存纹理的引用。多个 Rectangle、Ellipse 或其他形状使用同一个 BitmapCacheBrush 时，GPU 端只存储一份纹理数据，多个绘制调用使用不同的 UV 坐标采样同一纹理。

内存影响：

• 无共享：3 个元素各用 BitmapCache → 3 份纹理 → 3× VRAM
• BitmapCacheBrush 共享：1 个源用 BitmapCache + 2 个用 BitmapCacheBrush 引用 → 1 份纹理 → 1× VRAM

在需要将同一复杂 UI 片段渲染到多个位置的场景（如分屏预览、画中画、缩略图），BitmapCacheBrush 共享是关键的 VRAM 优化手段。

3.4 纹理释放时机

BitmapCache 的 D3D9 纹理释放遵循以下路径（按从快到慢排序）：

最重要的实践建议：

永远不要依赖 GC 来释放 BitmapCache 的 VRAM。 在你认为"该释放了"的时刻，显式设置 CacheMode = null。

原因：

1. BitmapCache 对象可能因事件订阅、绑定引用等原因长于预期存活
2. 即使托管对象被回收，Finalizer 的执行时机完全不确定
3. Gen2 GC 的触发频率极低——对用户而言，VRAM 在肉眼可见的时间窗口内"泄漏"
4. dotnet/wpf Issue #9467 证实了 .NET 9 中存在 WPF 控件 GC 回归问题

释放模式示例：

// 好的做法：显式释放privatevoidOnPanelHidden(){    MyComplexPanel.CacheMode = null;  // 立即释放纹理}// 坏的做法：依赖 GCprivatevoidOnPanelHidden(){    MyComplexPanel.Visibility = Visibility.Collapsed;// BitmapCache 纹理仍在 VRAM 中，直到 GC 决定回收}

3.5 软件渲染回退时的存储变更

当 WPF 在 Tier 0（软件渲染）或显式设置 RenderMode.SoftwareOnly 时运行，BitmapCache 的存储介质发生根本变化：

在软件渲染下：

• BitmapCache 退化为一个系统内存中的 IWICBitmap
• 每次呈现时，整个位图通过 CPU 从系统内存拷贝到窗口表面
• 此过程称为"双重拷贝"——源内容渲染到缓存位图（第一遍），缓存位图拷贝到窗口（第二遍）
• 这完全抵消了 BitmapCache 的设计优势——它本来是为了"渲染一次、GPU Blit 多次"，现在变成了"渲染一次、CPU 拷贝多次"

3.6 与 D3DImage 共享纹理的场景

D3DImage 是 WPF 中桥接 D3D9/D3D11 原生渲染的机制。在特定配置下，BitmapCache 和 D3DImage 可以共享同一个 D3D9 设备，但不能直接共享同一个纹理：

• 共享设备：BitmapCache 和 D3DImage 在同一窗口内共享 WPF 内部的 D3D9 Device（IDirect3DDevice9Ex）。这避免了多设备上下文切换开销。
• 不共享纹理：BitmapCache 纹理是 WPF MIL 层内部创建的渲染目标，其生命周期由 MIL 管理。D3DImage 纹理是由应用程序创建的外部纹理。两者互不知晓对方的存在。
• 跨 API 桥接：若要通过 D3D11 渲染内容并在 BitmapCache 旁显示，必须使用 DXGI Surface Sharing。微软参考实现：WPFDXInterop。

内存影响：当同时使用 BitmapCache（多个）和 D3DImage 时，VRAM 消耗是两者的叠加。没有内部共享机制减少消耗。在 VRAM 有限的设备上（如集成显卡、虚拟机），需要格外关注总使用量。

3.7 GDI 句柄耗尽陷阱

这是一个在生产环境中频繁出现但极少被正确诊断的问题。当应用中大量使用 BitmapCache 时，dotnet/wpf Issue #8031 揭示了一个关键根因：每个 BitmapCache 在 MIL 原生层需要分配 GDI 区域对象（通过 CreateRectRgn() API）来追踪缓存内部的脏区域。

问题：Windows 对每个进程有 10,000 个 GDI 句柄的默认限制（可通过注册表 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota 调整）。

后果：在 Issue #8031 报告的案例中，约 4,800-5,200 个 BitmapCache 实例（每个约消耗 1-2 个 GDI 句柄，具体取决于进程内其他 GDI 对象的消耗）触发了 CreateRectRgn() 返回 NULL，导致 COMException (HRESULT 0x88980406): UCEERR_RENDERTHREADFAILURE，渲染线程崩溃。

推理依据：Issue #8031 的社区讨论确认了 CreateRectRgn 调用与 GDI 句柄耗尽之间的因果链。dotnet/wpf 仓库中 MIL 层的源码注释（"Future: Do not allocate for non-mapped targets."）表明 WPF 团队早已意识到此设计缺陷，但截至 2026 年仍未修复。

缓解措施：

1. 限制同时存在的 BitmapCache 数量（< 5,000）
2. 使用 BitmapCacheBrush 共享纹理而非创建新缓存实例
3. 实现 MarkupExtension 返回共享的 BitmapCache 实例
4. 考虑提升系统 GDI 配额（治标不治本）
5. 对于大量重复元素的场景（如列表项），使用 VirtualizingStackPanel + 少量缓存模板，而非每个项单独缓存

四、软件渲染回退

4.1 RenderCapability.Tier 与 CacheMode 交互

WPF 的渲染层级系统（Tier System）将硬件能力分为三级：

检测代码：

int tier = RenderCapability.Tier >> 16;  // 0, 1, or 2int maxTextureSize = RenderCapability.MaxHardwareTextureSize;

重要区别：

• RenderCapability.Tier 报告硬件能够做什么（能力）
• HwndTarget.RenderMode 控制实际使用什么模式（决策）
• 手动设置 RenderMode.SoftwareOnly不会改变 RenderCapability.Tier 的值
• RenderCapability.TierChanged 事件仅在硬件配置变化时触发（如窗口跨 GPU 移动、RDP 连接/断开），不响应 RenderMode 手动切换

Tier 0 下 BitmapCache 的详细行为：

1. 不使用 D3D9 纹理——缓存存储在 IWICBitmap（系统内存）
2. 每个渲染帧，缓存的位图通过 CPU 指令（memcpy）拷贝到窗口后备缓冲区
3. 渲染线程受 CPU 带宽限制，而非 GPU 填充率
4. 最大缓存尺寸硬限制为 2048 × 2048（超过则降采样）

4.2 Tier 2 最优路径

在 Tier 2（完整硬件加速）下，BitmapCache 的最优渲染路径如下：

[帧 N] 缓存创建  Render 线程：渲染子树 → D3D9 渲染目标纹理（VRAM）  → 纹理句柄绑定到缓存合成节点[帧 N+1...N+K] 缓存复用  合成器线程：  ├── 检测缓存干净（无 dirty 标记）  ├── 直接绑定缓存纹理为采样源  └── GPU Blit（单个 DrawPrimitive 调用）      → 全窗口合成 → DWM Flip → 屏幕[帧 N+K+1] 缓存脏了  合成器线程：  ├── 检测缓存 dirty 标记  ├── 释放旧纹理  ├── 创建新渲染目标纹理（新尺寸/格式）  ├── 重新渲染子树到新纹理  └── 后续帧复用新纹理

GPU Blit 开销对比：

• 无缓存：每个子元素独立 D3D Draw 调用（数十到数百次）
• 有缓存：1 次 D3D Draw 调用（渲染一个带纹理的四边形）

这个差距在包含 100+ 子元素的复杂面板上可能是 20-50× 的 CPU 瓶颈缩减（因为 Draw 调用的 CPU 端开销远大于 GPU 端开销），而非 GPU 时间的缩减。

4.3 软件渲染下的存储格式与性能对比

实际存储格式

在 Tier 0（软件渲染）下：

• 缓存不是 D3D9 纹理，而是 IWICBitmap（Windows Imaging Component 的内存位图）
• 像素格式仍然是 PBGRA32（Premultiplied Alpha BGRA）
• 数据结构是简单的连续内存块：width × height × 4 bytes，行优先排列
• 位图存储在当前进程的私有内存中（可在任务管理器中观察）

性能对比

核心结论：在 Tier 0（软件渲染）下，BitmapCache 通常会让性能更差。这是因为：

1. 缓存创建增加了额外的渲染遍历（第一层拷贝）
2. 每帧的 memcpy（第二层拷贝）抵消了缓存复用的收益
3. CPU 端的位图拷贝比 GPU 端的纹理 Blit 慢一个数量级

实践指导：

publicstatic CacheMode GetOptimalCacheMode(UIElement element){int tier = RenderCapability.Tier >> 16;if (tier == 0)returnnull;  // 软件渲染：不使用缓存if (tier == 1)    {// 部分硬件加速：仅对小元素使用缓存，避免纹理尺寸限制if (element.RenderSize.Width * element.RenderSize.Height > 512 * 512)returnnull;    }returnnew BitmapCache    {        RenderAtScale = 1.0,        SnapsToDevicePixels = false,        EnableClearType = false    };}

五、调试与诊断工具

5.1 WPF Performance Suite / Perforator

Perforator（Perforator.exe）是 WPF Performance Suite 的核心工具，用于实时分析渲染管线行为。启用后提供以下关键视图：

前提条件：需要在 HKCU\SOFTWARE\Microsoft\Avalon.Graphics\ 下创建 EnableDebugControl DWORD = 1（此操作需要管理员权限，仅用于开发调试）。

但请注意：Perforator 随 Windows SDK 分发，较新的 Windows SDK 版本可能不再包含。替代方案包括使用 ETW（Event Tracing for Windows，Windows 内核级事件追踪机制，WPF 通过 ETW Provider 暴露渲染管线的内部事件）事件追踪（见下文）。

5.2 RenderCapability.Tier 运行时监控

编程式监控

publicclassRenderingTierMonitor{publicstaticvoidInitialize()    {// 初始检测        LogCurrentTier();// 监听 Tier 变化        RenderCapability.TierChanged += (s, e) =>        {            LogCurrentTier();            AdjustCacheModeForCurrentTier();        };    }privatestaticvoidLogCurrentTier()    {int tier = RenderCapability.Tier >> 16;int maxTexture = RenderCapability.MaxHardwareTextureSize;bool isSoftware = RenderOptions.ProcessRenderMode == RenderMode.SoftwareOnly;        Debug.WriteLine($"[TierMonitor] Tier={tier}, " +$"MaxTextureSize={maxTexture}, " +$"SoftwareMode={isSoftware}");    }privatestaticvoidAdjustCacheModeForCurrentTier()    {int tier = RenderCapability.Tier >> 16;if (tier == 0)        {// 移除所有 BitmapCache，软件渲染下不可用            DisableAllBitmapCaches(Application.Current.MainWindow);        }    }privatestaticvoidDisableAllBitmapCaches(Visual root)    {for (int i = 0; i < VisualTreeHelper.GetChildrenCount(root); i++)        {var child = VisualTreeHelper.GetChild(root, i) as UIElement;if (child != null)            {                child.CacheMode = null;                DisableAllBitmapCaches(child);            }        }    }}

ETW 事件追踪

WPF 通过 ETW Provider 暴露渲染事件。可以使用 PerfView 或 Windows Performance Recorder (WPR) 捕获：

# 使用 dotnet-trace (.NET Core 3.0+)dotnet-trace collect --providers Microsoft-Windows-WPF:0xFFFFFFFF:5 -- MyApp.exe

WPF ETW 事件的关键分析维度：

• WClientRenderThread：渲染线程的帧时间分布
• Layout：布局计算的耗时和频率
• MediaContext：DUCE 通道的通信流量
• Hardware Rendering Stats：每帧的 HW IRT 数量和 Draw 调用次数

在 BitmapCache 分析中，关注帧时间从"生成纹理"模式切换到"复用纹理"模式的转折点，以及 HW IRT 数量是否随帧数增长（暗示纹理泄漏）。

5.3 GPU 查看工具

GPU-Z

GPU-Z 的 "Sensors" 标签页（或新版本的 "VRAM Usage" 图）是验证 BitmapCache VRAM 消耗的最简单工具：

实验步骤：

1. 打开 GPU-Z，切到 Sensors 标签页
2. 记录基准 VRAM 使用量
3. 启动 WPF 应用程序（无 BitmapCache）
4. 记录 VRAM 使用量 = 基准值
5. 添加一个 1920×1080 全屏 BitmapCache 面板
6. 观察 VRAM 增量 ≈ 8 MB（1920×1080×4 bytes）
7. 设置 CacheMode = null，触发 GC
8. 观察 VRAM 是否回落到基准值

如果 VRAM 没有回落：说明存在纹理泄漏——缓存被创建后从未被释放。常见原因：

• BitmapCache 对象的引用仍被持有（事件订阅、绑定等）
• 元素仍在 VisualTree 中但不可见
• 使用了 BitmapCacheBrush 且引用未释放

Visual Studio Graphics Debugger

VS Graphics Debugger 可以捕获单个帧的所有 D3D9 调用，帮助确认 BitmapCache 纹理的实际分配：

1. Debug → Graphics → Start Graphics Debugging
2. 在应用中触发你想分析的场景
3. 点击 "Capture Frame"
4. 在 Object Table 中搜索 2D Texture 对象
5. 对比纹理尺寸和 Format 与 BitmapCache 参数的预期值
6. 在 Event List 中跟踪 SetRenderTarget / SetTexture 调用，观察缓存纹理何时被创建和使用

注意事项：

• Graphics Debugger 显示的是原始 D3D9 调用，没有与 BitmapCache 托管对象的直接映射
• 需要通过纹理尺寸（× RenderAtScale × DPI）来间接匹配
• 对于 BitmapCache（作为合成器内置纹理），纹理可能命名为 "CompositionTarget" 或类似名称

5.4 性能测试代码：阈值参数对重绘次数的影响

以下是最小可复现的性能测试代码，用于验证不同阈值参数对 TileBrush（VisualBrush）缓存重绘次数的影响：

<!-- ThresholdBenchmark.xaml --><Windowx:Class="ThresholdBenchmark.MainWindow"xmlns="(WPF 标准 XAML 命名空间)"xmlns:x="(WPF 标准 XAML 命名空间 x)"Title="CacheInvalidationThreshold Benchmark"Width="800"Height="600"><DockPanel><!-- 控制区 --><StackPanelDockPanel.Dock="Top"Orientation="Horizontal"Margin="10"><TextBlockText="Minimum:"VerticalAlignment="Center"Margin="0,0,5,0" /><TextBoxx:Name="MinThresholdBox"Text="0.5"Width="60"Margin="0,0,15,0" /><TextBlockText="Maximum:"VerticalAlignment="Center"Margin="0,0,5,0" /><TextBoxx:Name="MaxThresholdBox"Text="2.0"Width="60"Margin="0,0,15,0" /><Buttonx:Name="ApplyButton"Content="Apply &amp; Reset"Click="OnApplyClick"Margin="0,0,15,0" /><Buttonx:Name="ScaleButton"Content="Animate Scale"Click="OnAnimateScaleClick" /></StackPanel><!-- 统计区 --><StackPanelDockPanel.Dock="Top"Margin="10,0"><TextBlock><RunText="Cache Regenerations: " /><Runx:Name="RegenCountText"Text="0"FontWeight="Bold"Foreground="Red" /></TextBlock><TextBlock><RunText="Current Render Scale: " /><Runx:Name="CurrentScaleText"Text="1.00" /></TextBlock><TextBlock><RunText="Cached Size: " /><Runx:Name="CachedSizeText"Text="N/A" /></TextBlock><TextBlock><RunText="Requested Size: " /><Runx:Name="RequestedSizeText"Text="N/A" /></TextBlock></StackPanel><!-- 测试区域：VisualBrush 绑定的源 Grid --><GridDockPanel.Dock="Bottom"Height="400"Background="Black"><Rectanglex:Name="TestRectangle"Width="400"Height="400"><Rectangle.RenderTransform><ScaleTransformx:Name="TestScale"ScaleX="1.0"ScaleY="1.0" /></Rectangle.RenderTransform><Rectangle.Fill><VisualBrushx:Name="TestBrush"RenderOptions.CachingHint="Cache"RenderOptions.CacheInvalidationThresholdMinimum="0.5"RenderOptions.CacheInvalidationThresholdMaximum="2.0"><VisualBrush.Visual><Gridx:Name="SourceGrid"Width="400"Height="400"Background="White"><Grid.RowDefinitions><RowDefinitionHeight="*" /><RowDefinitionHeight="*" /></Grid.RowDefinitions><EllipseGrid.Row="0"Fill="Red"Margin="20" /><TextBlockGrid.Row="1"Text="Test Visual Content"FontSize="24"HorizontalAlignment="Center"VerticalAlignment="Center" /></Grid></VisualBrush.Visual></VisualBrush></Rectangle.Fill></Rectangle></Grid></DockPanel></Window>

// ThresholdBenchmark.xaml.csusing System;using System.Windows;using System.Windows.Media;using System.Windows.Media.Animation;namespaceThresholdBenchmark{publicpartialclassMainWindow : Window    {privateint _regenCount = 0;private Size _lastCachedSize = Size.Empty;publicMainWindow()        {            InitializeComponent();// 通过监听 LayoutUpdated 间接检测缓存重生成// 当缓存重生成时，VisualBrush 的源元素会经历一次布局/渲染周期            CompositionTarget.Rendering += OnRendering;// 更准确的检测：监听 SourceGrid 的 LayoutUpdated            SourceGrid.LayoutUpdated += OnSourceLayoutUpdated;        }privatevoidOnRendering(object sender, EventArgs e)        {// 更新当前渲染尺寸var scaleX = TestScale.ScaleX;            CurrentScaleText.Text = $"{scaleX:F2}";var cachedWidth = TestRectangle.Width * scaleX;var cachedHeight = TestRectangle.Height * scaleX;            RequestedSizeText.Text = $"{cachedWidth:F0}×{cachedHeight:F0}";        }privatevoidOnSourceLayoutUpdated(object sender, EventArgs e)        {// 注意：LayoutUpdated 在每次布局遍中都会触发，而缓存重建是 MIL 层的内部操作。// 此计数为近似值——LayoutUpdated 是缓存重生成的上级触发事件而非精确一一对应。// 用于同一测试会话内的相对比较可行，但不宜作为绝对值引用。            _regenCount++;            RegenCountText.Text = _regenCount.ToString();        }privatevoidOnApplyClick(object sender, RoutedEventArgs e)        {// 应用新的阈值参数if (double.TryParse(MinThresholdBox.Text,outdouble minThreshold) &&double.TryParse(MaxThresholdBox.Text,outdouble maxThreshold))            {                TestBrush.SetValue(                    RenderOptions.CacheInvalidationThresholdMinimumProperty,                    minThreshold);                TestBrush.SetValue(                    RenderOptions.CacheInvalidationThresholdMaximumProperty,                    maxThreshold);// 重置缩放和计数器                TestScale.ScaleX = 1.0;                TestScale.ScaleY = 1.0;                _regenCount = 0;                RegenCountText.Text = "0";// 强制刷新以应用新阈值                TestBrush.InvalidateProperty(                    RenderOptions.CacheInvalidationThresholdMinimumProperty);                TestBrush.InvalidateProperty(                    RenderOptions.CacheInvalidationThresholdMaximumProperty);                SourceGrid.InvalidateVisual();            }        }privatevoidOnAnimateScaleClick(object sender, RoutedEventArgs e)        {// 缩放动画：从 4.0x 缩小到 0.1x，再回到 1.0xvar anim = new DoubleAnimation            {                From = 4.0,                To = 0.1,                Duration = TimeSpan.FromSeconds(2),                AutoReverse = true,                RepeatBehavior = new RepeatBehavior(2) // 来回 2 次            };            anim.Completed += (s, args) =>            {// 动画结束后输出统计                MessageBox.Show($"Animation completed.\n" +$"Total cache regenerations: {_regenCount}\n" +$"MinThreshold: {MinThresholdBox.Text}\n" +$"MaxThreshold: {MaxThresholdBox.Text}","Benchmark Result");            };            TestScale.BeginAnimation(ScaleTransform.ScaleXProperty, anim);            TestScale.BeginAnimation(ScaleTransform.ScaleYProperty, anim);        }    }}

测试方法

1. 默认阈值测试（Min=0.5, Max=2.0）：

• 点击 "Animate Scale"
• 记录动画完成后的 _regenCount（预期：约 4-8 次，取决于动画帧率和缓存大小）

2. 宽阈值测试（Min=0.1, Max=10.0）：

• 修改文本框值 → 点击 "Apply & Reset" → 点击 "Animate Scale"
• 预期：重生成次数大幅减少（约 1-3 次），因为大部分缩放范围在阈值区间内

3. 零阈值测试（Min=0, Max=0）：

• 修改文本框值 → 点击 "Apply & Reset" → 点击 "Animate Scale"
• 预期：重生成次数显著增加（与动画帧数接近），因为每次缩放变化都触发重生成

4. 窄阈值测试（Min=0.8, Max=1.2）：

• 预期：重生成次数非常高，因为很小的缩放变化（>20%）就触发重建

预期结果解读

此测试框架可以扩展到测试 BitmapCache（而非 TileBrush）的重绘频率——只需将 Rectangle 的 Fill 改为对 BitmapCacheBrush 的引用，并监听目标元素的变化。

总结

本文深入剖析了 WPF BitmapCache 生命周期中三个关键维度：失效触发、阈值控制与显存管理。核心要点归纳如下：

1. 缓存失效：五类触发，三层传递

缓存失效由五个维度触发——布局变化（Arrange finalSize）、渲染变化（RenderTransform / Clip）、视觉效果变化（Opacity / Effect）、缓存自身属性变化（RenderAtScale）、显式失效（InvalidateVisual）。每种失效通过托管层 dirty flag → DUCE 通道序列化 → MIL 层缓存脏检测三层链路传播，最终在 VSync 边界触发纹理重建。

2. 脏矩形合并：单帧内多次失效合并为一次重建

脏矩形系统通过在帧内将多个失效累积、去重、合并为少数脏区域进行处理。值得重视的是：脏矩形系统优化的是后→前缓冲区拷贝，而非渲染粒度——BitmapCache 纹理始终全量重建，不论脏区域多小。

3. 阈值机制：两套缓存，不要混淆

RenderOptions.CacheInvalidationThresholdMinimum 和 Maximum 是 TileBrush（VisualBrush / DrawingBrush）的缓存阈值，控制基于渲染尺寸比值的重生成时机。BitmapCache（UIElement.CacheMode）使用内容变化驱动的失效逻辑，通过 RenderAtScale 而非阈值属性控制纹理质量。两者在嵌套使用时产生层叠失效效应。

4. GPU 显存 = 托管遥控器 + 非托管纹理

BitmapCache 的托管对象仅几十字节，但遥控的 D3D9 纹理可达数十 MB。纹理尺寸公式为 W × H × RenderAtScale × DpiScaleX × DpiScaleY × 4 bytes。释放必须显式（CacheMode = null），不可依赖 GC。GDI 句柄耗尽（~5000 缓存实例的硬上限）是生产环境中最危险且最易被误诊的故障模式。

5. Tier 0 下 BitmapCache 反成性能杀手

软件渲染下缓存存储在系统内存 IWICBitmap 中，每帧 CPU memcpy 抵消了缓存复用的全部收益。建议在 Tier ≤ 0 时移除所有 BitmapCache。

6. 调试工具箱

Perforator + GPU-Z + VS Graphics Debugger 三者结合可覆盖从托管层属性到原生 D3D9 纹理的完整诊断链路。文中提供的 ThresholdBenchmark 性能测试代码可作为参数调优的起点。

引用

官方文档与源码

1. Microsoft Learn — RenderOptions.CacheInvalidationThresholdMinimum Property — 官方 API 文档
2. Microsoft Learn — RenderOptions.CacheInvalidationThresholdMaximum Property — 官方 API 文档
3. Microsoft Learn — BitmapCache Class — 官方 API 文档
4. Microsoft Learn — Graphics Rendering Tiers — Tier 体系完整说明
5. Microsoft Learn — RenderCapability.Tier Property — Tier 检测 API
6. Microsoft Learn — Graphics Rendering Registry Settings — WPF 注册表配置键
7. Microsoft Learn — WPF Architecture — WPF 架构概述
8. Microsoft Learn — Performance Considerations for D3D9 and WPF Interoperability — D3D9/WPF 互操作
9. Microsoft Learn — WPF Performance Profiling Tools) — Perforator 使用指南
10. Microsoft Learn — MS-WPFXV-2019: BitmapCache — Open Specifications 中 BitmapCache 的定义
11. Microsoft Archives Blog (Lester Lobo) — New WPF Features: Cached Composition — Cached Composition 功能原始设计文档
12. Microsoft Archives Blog (J. Goldberger) — What's New for Performance in WPF in .NET 4 — .NET 4 中的性能改进

dotnet/wpf 仓库关键源文件

1. RenderOptions.cs — 阈值属性的依赖属性注册、默认值与访问器
2. BitmapCache.cs — BitmapCache 实例属性（RenderAtScale、EnableClearType、SnapsToDevicePixels）
3. UIElement.cs — InvalidateVisual、InvalidateArrange、OnRender 及相关 dirty flag 管理
4. dotnet/wpf 仓库 src/WpfGfx/core/sw/swlib/ — MIL 层软件渲染双缓冲和脏矩形管理（C++ 部分开源）
5. dotnet/wpf 仓库 src/WpfGfx/core/ — MIL 层渲染目标基类，包含 GDI Region 分配的源码注释

GitHub Issues & Community

1. dotnet/wpf #8919 — "Regarding WPF BitmapCache Issue + R&D + Solutions" — 最全面的 BitmapCache 冻结问题深度分析，包含 DisableDirtyRegionSupport 补丁
2. dotnet/wpf #8031 — "Massive use of BitmapCache leads to UCEERR_RENDERTHREADFAILURE" — GDI 句柄耗尽问题与 CreateRectRgn NULL 返回
3. dotnet/wpf #4276 — "WPF Rendering issue on any machine" — 多窗口 BitmapCache 渲染冻结原始报告
4. dotnet/wpf #8960 — "Indeterminate progress bar used as BitmapCacheBrush target do not animate" — BitmapCacheBrush 动画回归（.NET 7+）
5. dotnet/wpf #9161 — "Artifacts when using BitmapCacheBrush" — BitmapCacheBrush 渲染伪影
6. dotnet/wpf #9164 — "Flowdocument's image memory usage exception" — 图像内存使用异常
7. dotnet/wpf #9467 — "WPF control is not reclaimed on NET9 by GC" — .NET 9 GC 回归
8. dotnet/wpf #1082 — "Memory held by the resources is not released even after disposing" — CLR 内存释放行为说明
9. dotnet/wpf #39 — "Allow BitmapSource to invalidate its image cache ptr" — BitmapSource 缓存失效 API 功能请求
10. dotnet/wpf #10005 — "Memory leak on some graphic cards" — 特定显卡上的内存泄漏

深度技术分析

1. Lindexi（林德熙）— dotnet 读 WPF 源代码笔记：WriteableBitmap 的渲染和更新是如何实现 — WPF MIL 层 C++ 脏矩形管理机制深度分析
2. Lindexi（林德熙）— WPF 从最底层源代码了解 AllowsTransparency 性能差的原因 — WPF 渲染管线底层分析
3. Microsoft Reference Source — IndependentAnimationStorage.cs — DUCE 通道资源更新模式的标准实现参考
4. Microsoft Source — UpdateResource — DUCE.IResource.UpdateResource 实现参考
5. Stack Overflow — BitmapCache Size — WPF 缓存尺寸限制的社区讨论
6. Microsoft WPFDXInterop — GitHub — D3D11-to-D3D9 surface sharing 参考实现
7. Visual Studio — Graphics Diagnostics Overview — VS Graphics Debugger 官方文档

系列导航：[WPF BitmapCache 源码解构（一）：从业务卡顿到渲染管线定位] | [（二）：托管属性到 GPU 纹理的完整链路] | [（三）：BitmapCacheBrush 缓存复用与 RenderAtScale 分辨率控制] | （四）缓存失效、阈值控制与显存管理（本文） | [（五）：版本演进、已知限制与实战调优]

本文基于 dotnet/wpf 仓库 main 分支（2026-06）、.NET 9.0 及 Windows 11 环境编写。文中代码示例均为简化表示，实际源码请以 GitHub 仓库为准。