WebView (macOS): don't promote WKWebView to layer-backed for bg colour (fixes secondary-monitor blur)

[jakepenn]

Problem

Some users report the player webview rendering blurry on a secondary monitor (Retina ↔ non-Retina, or two displays at different scales).

Root cause: the macOS background-colour path (AppleWkWebView::withBackgroundColour, which we use to suppress the first-paint white flash) promoted the WKWebView to a layer-backed view:

[webView setWantsLayer: YES];
layer.backgroundColor = CGColorGetConstantColor (kCGColorClear);

That promotion pins the view's root-layer contentsScale at creation time. When the host window then moves to a display with a different backingScaleFactor, high-DPI content is composited into a stale backing and reads as pixelated/blurry. A plain (layer-hosting) WKWebView — what CHOC, wry and Safari use — lets WebKit keep the backing scale in sync across display moves automatically.

Change

Drop the setWantsLayer:YES + transparent layer.backgroundColor block. The WKWebView stays layer-hosting (its default). First-paint flash suppression is unchanged — it relied on drawsBackground = NO and setUnderPageBackgroundColor, both kept. The under-page background now shows the chrome colour rather than a clear layer.

The viewDidChangeBackingProperties re-stamp (added in #32 to chase the pinning) is left in place as a harmless backing-scale safety net.

Testing

• First-paint white flash still suppressed (no flicker on load) with the chrome background colour
• Webview sharp when the plugin window is moved between displays of differing backing scale
• Verified in plugin host on a dual-monitor Retina + non-Retina setup

🤖 Generated with Claude Code