在 Windows 8 我们引入了新的图形API：DirectComposition，这是一个高性能的位图合成引擎并以经典的COM API公开其功能。在此基础上提供了基于Windows 运行时平台的 Windows.UI.Composition 和 Microsoft.UI.Composition API（WindowsAppSDK）。因此这是自 Windows Vista 引入桌面窗口管理器（DWM）之后一次更全面的对 DWM 相关 API 进行的革新和改进，因为后续的 WinRT XAML 包括UWP XAML，WinUI3 XAML等都基于DirectComposition API 构建，作为新一代的系统原生 UI 框架。

我们今天的重点不在于讨论如何使用 DirectComposition API 以及它的等效运行时投影 API集合，不知你是否思考过为什么 UWP XAML Window 在 Resizing 时能够保持一个平滑的视觉更新以及内容布局完全同步调整的良好体验而其他的大多数第三方 UI 平台难以做到这一点，即使是新一代的 WinUI3 XAML Window 也尚未妥善处理？

是的，如果你曾经有过这个疑惑，或者你正在面临你开发所使用的 UI 框架应用程序在窗口 Resizing 时内容发生撕裂，抖动，闪烁等糟糕的体验，我接下来的一些讲解和答复可能有助于你改善或解决这个情况。显而易见的，在处理这类情况时例如 UWP XAML Window 这类基于 DirectComposition 构建的应用程序界面，我们并未使用像 DirectX 提供的等待垂直空白，以及驱动程序抽象层的垂直回扫周期等这些公开的 API。因为这类 API 并不能帮助你的应用内容绘制和呈现与 DWM 系统合成器保持完全同步，因此一些糟糕的 Resizing 体验是在所难免的。

我们在Windows 11 Build 22000中提供了一个新的 DirectComposition 函数：DCompositionWaitForCompositorClock ，该函数向开发者提供了一个更明确的系统合成器时钟，并通过等待可以让你有机会在 DWM 进行下一次内容采样之前执行一些图形更新以及内容布局调整操作来确保在下一个合成器帧时间内尽可能的获取到你提供的最新帧并最终进行组合呈现到屏幕。大多数情况下如果你的应用绘制速度足够快，能够在确定的时间内完成提交最新的内容到队列以及缓冲区，那么 Resizing 时大部分糟糕体验都可以避免，减少。

当然，这种情况通常并不能达到你想要的理想结果，你的应用程序绘制所需的时间相比与 DWM 所给定的时间而言是发生了“超时”，那么最终在屏幕上看到的就是相当糟糕的视觉灾难。因此，既然你的应用并不能时刻稳定快速的提交最新的内容给系统合成器，那么你就会要求 DWM 在采样你的应用内容时进行同步等待，直到你确认已经完成了最新的内容布局调整和绘制后再继续合成。事实上 UWP XAML Window 或更准确的说是 CoreWindow 执行了这样的例程。

因为这是我们内部使用的系统私有 DirectComposition API，不保证其在构建迭代时稳定可用。IDCompositionDevicePartner X 系列的接口提供了特定于一些场景的应用窗口可以向 DWM Compositor 请求在提交最新的视觉更改时进行同步等待，直到应用给出所需的事件信号或通知的方法。这使得合成引擎可以原子化合成应用程序内容最终完美的呈现到屏幕。

看到这里你可能会有一个新的疑惑，为什么看似是对 UWP 一脉相承的 WinUI3 桌面应用程序却无法做到这一点。事实上我们在将 UWP XAML 部分提升出来后进行了一些重新编写，在 ABI 层面上两者是不兼容的，因此在这个方面无法直接向 DWM 请求现有的 Resize 优化的 DComp 视觉提交链路，并且WinUI3 XAML目前只能使用 ContentIsland 托管在一个中间 HWND 窗口中即 “BridgeWindow”。因此，种种原因导致其无法像 UWP CoreWindow 一样直接使用相同的私有 API 来改进窗口 Resizing 体验。不过好消息是我们在这个问题的处理上已经取得了初步效果：请阅 microsoft/microsoft-ui-xaml5148

我们在 WindowsAppSDK 中为 WindowsSDK 中的 IDCompositionDevicePartner 系列编写了新的等效 API 以支持 DWM 对 WinUI3 XAML Window 提供可用的 Resize 优化的合成提交链路。当然我们仍然还需要很多工作要做，确保在将更多的 WinUI3 XAML 元素加入到系统中时能够解决更多的基础性问题以及一些历史遗留性问题。因此我们减缓了对WindowsAppSDK 2.0的更多实验性功能的开发，而专注于打磨修复框架自身的质量和稳定性。

说到最后，由于版权以及保密性要求，我可以向你们透露较为简单的实现原理以帮助你所开发的应用程序来改进窗口 Resizing 体验。对于加入系统支持的 DComp Resize 同步优化链路，你需要为你的应用程序创建一个由 DesktopWindowXamlSource 类托管的 XAML 宿主环境（可以不创建可见的额外 UI 元素）以达到系统要求的部分基础条件，这可以是 Windows.UI.Xaml.Hosting.DesktopWindowXamlSource 也可以是 Microsoft.UI.Xaml.Hosting.DesktopWindowXamlSource（当前最新稳定的 WindowsAppSDK 中尚未可用，将在稍后完善对系统要求的 XAML 桌面宿主环境检测）。DWM 系统合成器提供的支持以窗口句柄（HWND）为单例，仅支持一个顶级窗口 && 所有者窗口，不支持其任意子窗口。在向 DWM 注册窗口后，系统将会为该窗口注册一个不可见的合成表面并作为内容并连接到位于底层的 HWND DirectComposition 可视化树，子窗口将始终显示在此可视化树上层并裁剪可视化树。当你的应用窗口开始进入 Size-Move Modal Loops（大小位置调整模态循环，通过WM_SYSCOMMAND 或 WM_ENTERSIZEMOVE消息确定），你可以在 WM_WINDOWPOSCHANGED 或 WM_SIZE 消息到达窗口过程时进行处理并通知你的应用内容开始更新布局和绘制，此时你请求 DWM 系统合成器进行同步等待直到你的应用内容已经更新完成并进行提交。最终，你的应用程序将良好的呈现在屏幕上。

如果你想要获取更具体的细节，或者想与我讨论一些问题，欢迎致电！

另请参阅
DirectComposition
DCompositionWaitForCompositorClock 函数
 DesktopWindowXamlSource Class