NativeWidgetMacNSWindowHost warm up compositor before window is shown

提交: ae5a92b7 | 2026-04-30 20:58:05

← 返回列表

NativeWidgetMacNSWindowHost warm up compositor before window is shown

Moderate
提交哈希: ae5a92b7f18b9d8110e8a7435651fea1ec7e3079
提交时间: 2026-04-30 20:58:05
影响等级: Moderate
生成工具: chromium-watcher
上游审核链接: 查看上游审核 🔗

📋 摘要

This commit optimizes the window show sequence. Previously, the compositor was only initialized after the NSWindow visibility notification callback (OnVisibilityChanged), causing potential UI thread hangs during window animation. Now, SetVisibilityState preemptively calls OnVisibilityChanged(true) to warm up the compositor before the Cocoa window show call. The old hack in ShowAsModalSheet that pretended the window was already visible is removed since the new mechanism covers that case.

🎯 影响分析

This commit has moderate impact on WebView2Mac. Changes involve two core files:
1. NativeWidgetMacNSWindowHost::SetVisibilityState — adds preemptive compositor warmup logic that calls OnVisibilityChanged(true) before the Cocoa show call when the window is about to become visible and its parent is also visible. The Edge downstream currently lacks this logic; during merge, care is needed around interaction with Edge's WidgetActivationDelegate and macOS 14 yield activation code.
2. NativeWidgetNSWindowBridge::ShowAsModalSheet — removes the code that set window_visible_ = true and called host_->OnVisibilityChanged(). Edge downstream still has this old code (native_widget_ns_window_bridge.mm:2184-2186) and it will be deleted during merge.
WebView2Mac uses in-process window mode where Host and Bridge are in the same process, so the compositor warmup logic applies equally. If WebView2Mac has custom window show timing or modal sheet scenarios, verify that the preemptive compositor warmup does not cause duplicate Unsuspend calls or state inconsistencies.

受影响的类:

NativeWidgetMacNSWindowHost NativeWidgetNSWindowBridge