原生窗口与 DWM 材质#

Windows 的 DWM 负责桌面合成。Acrylic 作用在原生窗口背景上，能让窗口透出被系统处理过的桌面或其他窗口。

Wails 主窗口的相关配置为：

1
BackgroundType: application.BackgroundTypeTranslucent,
2
Windows: application.WindowsWindow{
3
    BackdropType: application.Acrylic,
4
    Theme:        application.SystemDefault,
5
},

在这个版本的 Wails 中，非 Solid 背景会让 WebView 的默认背景透明。对于可交互的透明窗口，Windows 实现还会设置 WS_EX_NOREDIRECTIONBITMAP。

这个标志值得检查，但后续对照证明：仅移除这个标志不能消除闪屏，不能把它当成充分的根因解释。

WebView2 / Chromium 的页面呈现#

HTML、布局、绘制和 GPU 合成发生在 WebView2 内。窗口尺寸通知到达浏览器，并不等于新尺寸的画面已经呈现在屏幕上。

Wails 的 WM_SIZE 处理会调用 ResizeWithBounds，最终更新 WebView2 的 PutBounds。这里的 InvokeSync 同步的是宿主调用，并没有承诺“浏览器已完成布局并提交这一帧”。

因此，至少要区分：

1
原生窗口边界变化
2
    ↓
3
WebView2 控制器收到新的 Bounds
4
    ↓
5
页面布局与绘制
6
    ↓
7
GPU 内容呈现、DComp 树更新
8
    ↓
9
DWM 合成到屏幕

中间某个步骤暂时没有覆盖到窗口区域时，原生窗口背景就可能露出来。

CSS 的透明面和 backdrop-filter#

Emulsion 的侧栏与内容区是并列布局。主内容不会从侧栏背后滚过，所以仅在一个平整、不透明的底色上写 backdrop-filter，很难获得真正的桌面磨砂。

经典外观的透明链路是：

• body 和窗口外壳让出底色。
• 主内容区铺不透明背景，保证正文不会整屏透出桌面。
• 侧栏和标题栏使用半透明面，让原生 Acrylic 透上来。
• CSS 模糊和色调处理放在伪元素上，避免改变祖先对 fixed 弹窗的包含块。

这也是为什么将窗口背景改成 Solid 后，侧栏会退化：即使 CSS 还写着模糊，原生透明链路也已经断开。

连续拖拽的对照结果#

给页面添加一个临时固定边缘标记，再用原生拖拽路径连续改变窗口大小。标记仅用于测试，不进入应用代码。

这些是固定拖拽轨迹下的屏幕像素测量，不是帧率测试，也不能直接换算成所有场景下的延迟毫秒数。

原来的“页面内容延迟加载”描述，实际更接近新尺寸的画面提交落后。无需网络请求的简化页面也能出现同类现象，所以不能仅靠页面加载速度解释。

哪些实验没有解决问题#

还有一些早期实验用了名字看起来相关的开关，例如 DirectCompositionUseDCompSurface、DirectCompositionSwapChainIndependentFlip。没有确认它们对当前 Chromium 153 主画面路径的实际作用，不能将“传了参数但没变化”写成已排除机制。

源码研究还发现视频覆盖层禁用开关采用下划线形式：

1
--disable_direct_composition_video_overlays

它不能与随手猜出的连字符写法等同；而且视频覆盖层本来就不是这个无视频复现页面的优先方向。整个排查过程中，参数能出现在命令行上，与它真正改变了目标路径，是两件事。

主画面内容与 DComp Commit 并非天然同步#

Chromium 153 的 DirectCompositionResizeFixes 默认开启。相关源码解释了一个重要时序：

presenting a frame and changing the DComp layer clip rect can happen at different times

也就是：呈现画面内容，与改变 DComp 图层的裁剪区域，可能发生在不同时间。

为处理缩放中的边界，代码会清理视口之外的区域，使其透明。对于透明宿主，这类透明区域可能露出原生窗口背景。

这个源码路径与观察到的现象相符，但还不足以证明 Microsoft 的 WebView2 分支内部具体在哪一步发生了异常。因此，更准确的判断是：对照实验把问题定位到了主画面呈现与 DComp 更新的配合；源码提供了同步策略的解释。

关键的另一段注释是：

With delegated compositing or a buffer queue, Present and Commit are synchronized and the clear is not needed.

这指向了 BufferQueue。

BufferQueue 改变的是主画面的缓冲策略#

Chromium 的功能定义描述：Windows 上启用 BufferQueue 后，主画面使用缓冲队列，替代 DXGI swap chain 或 DComp surface。

它保留 DirectComposition，不会把整个浏览器切回此前较慢的呈现路径。源码中的能力门槛为：

1
return support_level >= OutputSurface::DCSupportLevel::kDCompDynamicTexture &&
2
       base::FeatureList::IsEnabled(features::kBufferQueue);

因此，只开启功能名还不够。运行环境必须支持动态 DComp 纹理；不支持的系统可能继续使用普通路径。

浏览器截图可能漏掉原生闪帧#

CDP 或 Playwright 截图适合检查 DOM 和布局，但不能完整证明 DWM 没有在某一帧露出宿主背景。

这次使用 Win32 GDI 采样物理屏幕：

1. 根据窗口标题和进程 ID找到测试窗口，避免同时运行多个 Emulsion 时选错实例。
2. 先还原窗口，再读取屏幕坐标。
3. 使用 BitBlt 与 GetDIBits 获取屏幕像素。
4. 对静止的不透明内容小区域进行高频采样，保存异常最大的帧和 JSON 数据。
5. 对拖拽使用水平窄条采样，追踪固定紫色边缘标记，以及窗口边缘内侧的不透明内容。

闪屏测试采样约 100 次/秒以上，选择小区域才能获得足够时序覆盖。最初约 75ms 一次的大区域截屏就没有捕获到这类短暂异常，不能据此认定没有闪屏。

这仍然是采样验证，不是逐刷新周期录制所有帧；“未捕获异常”需要和可稳定复现的基线对照一起判断。

先保证测量本身有效#

排查中踩到了几个会制造“假通过”的坑：

• IsWindowVisible 返回真不代表窗口未最小化。最小化窗口可能位于 -32000 坐标，采样屏幕外会得到全零像素。
• ctypes 调 Win32 API 必须声明指针宽度正确的参数和返回类型，否则句柄可能截断，甚至只在资源释放时才报错。
• 窗口拖小后，固定的右边缘标记可能还没更新、被窗口裁掉。找不到标记不能直接解释为出现空白。
• 紫色边框会提高 RGB 平均值。检测 Acrylic 空白时必须排除边框颜色，检查另一块本应不透明的内容区域。
• 页面刷新后可能跳回连接页面。每轮测量前应确认路由、外观、主题以及侧栏确实存在。

原生拖拽测试复用了 Wails 启动缩放的消息路径：WM_NCLBUTTONDOWN 加对应边缘命中值。真实标题栏双击则另行发送鼠标点击，并检查 IsZoomed 在最大化和还原后分别成立、取消。

验证动作要覆盖两个时间阶段#

缩放之后的测试：

• 最大化，再还原。
• 普通尺寸变化。
• 分别等待 0.7、1.2、2、4 秒，再将鼠标移入会触发重绘的区域。
• 单独验证真实标题栏双击。

缩放过程中的测试：

• 连续拖大和拖小。
• 测页面边缘相对原生边界的落后像素。
• 检查新扩展区域是否露出亮色 Acrylic。
• 区分首轮与后续轮次，不能只选最好看的一组数据。

验证玻璃与 GPU 没被破坏#

DWM 属性 DWMWA_SYSTEMBACKDROP_TYPE 的属性编号是 38，读取结果 3 对应 Acrylic。

此外，在验证窗口后面放置临时红色、蓝色背景：

这证明侧栏确实还能透出原生背景，内容区也没有跟着变透明。检查仅使用临时背景窗口，没有修改桌面壁纸。

WebGL2 返回的渲染器仍是：

1
ANGLE (AMD, AMD Radeon 780M Graphics, Direct3D11)

因此，改善没有以关闭 GPU 或改用软件渲染为代价。

简化 Wails 页面#

真实 Desktop 经典外观#

真实页面比简化页面更重，首轮还可能出现更大的延迟。这次验证不能支持“所有元素零延迟”，能够支持的是：经典外观中旧方案引入的大片材质空白已消除，连续拖拽跟随显著改善，且没有重新引入原先的整窗闪帧。

液态玻璃不等于经典 Acrylic#

液态玻璃外观还包含 CSS 滤镜、SVG 折射、尺寸监听和材质重算。本次实测中，即使使用 BufferQueue，连续缩放仍有几十像素级的额外落后；首次悬停闪屏测试保持干净。

临时关闭滤镜后延迟也没有完全消失，因此只能判断它包含额外的页面渲染成本，不能将全部延迟简单归因于某一个滤镜或 ResizeObserver。

这一项尚未完成独立的前端性能优化，不能把经典外观的结果推广为两套外观都已同样流畅。

BufferQueue 有能力门槛，也不是永久稳定的 WebView2 API#

Chromium 的源码能力判断说明，不支持动态 DComp 纹理的系统可能保留普通呈现路径。命令行里看到功能名，只能证明参数传入，不能单独证明该路径已经激活。

本机通过行为对照得到有效结果；其他 GPU、较旧系统、不同 WebView2 版本、混合 DPI 多屏需要复测。Microsoft 也明确指出，浏览器功能标志可能变化，不应把它们当成长期稳定的公共 API。

因此，升级 WebView2 或 Wails 后，应该重跑以下三组验证：连续拖拽、缩放后首次悬停、Acrylic 与硬件渲染。不能只保留这行配置而忘记它依赖的运行时条件。