WebView2 (DComp swapchain) never presents when the target HWND is a reparented child — JUCE 8 audio-plugin editors

[blakebratcher]

Summary

A JUCE 8 WebBrowserComponent (WebView2) plugin editor renders nothing — the
host sees only the plugin's own placeholder background — when the editor HWND has
been reparented into a host window by an audio-plugin bridge (yabridge).

The same WebView2 runtime, same wine build, same prefix renders perfectly for a
normal top-level WebView2 app (Tauri/Minimal Hub). So the runtime and the d2d1/dcomp
stack work; the failure is specific to the composition target being an already-
reparented child window.

The web content itself is fully alive — this is purely a presentation failure:

• document.readyState = complete, 351 elements, stylesheets loaded (98 + 3 rules)
• document.visibilityState = visible (not an occlusion suspend)
• WebGL 2.0 works: clearColor(1,0,0,1) + readPixels returns 255,0,0,255
• Page.captureScreenshot via CDP returns an all-black image
  (also with fromSurface:false and captureBeyondViewport:true)

So raster works, but the composed frame never reaches the target window.

Environment

wine	wine-11.0-167-g46c43a2db62, branch d2d1-dcomp-11.0
WebView2 runtime	Evergreen 150.0.4078.83
Plugin	Minimal Audio "EPROM - Memory Rites" 1.1.0, VST3, JUCE 8.0.13
Bridge	yabridge 5.1.1-54-g48ea9749 (VST3, individually hosted)
Hosts	Carla 2.x and Bitwig Studio (identical symptom)
Prefix	Bottles, DXVK/VKD3D off (wined3d)
GPU	NVIDIA RTX 3090, proprietary driver

Reproduction

1. Install the WebView2 Evergreen runtime into the prefix.
2. Install a JUCE 8 plugin whose editor is a WebBrowserComponent (WebView2).
3. Bridge it with yabridge and open its editor in any host.

Editor shows the plugin's placeholder background only; web content never appears.

Control that works: run a normal top-level WebView2 app (e.g. a Tauri app) in the
same prefix with the same runner — it renders correctly. Only the embedded/reparented
plugin-editor case fails.

Relevant trace (WINEDEBUG=+dcomp)

dxgi:dxgi_factory_CreateSwapChainForComposition Created composition window 00000000000900F8 (1100x720) for swapchain 000000000D261A90.
dcomp:dcomp_device_CreateTargetForHwnd Created composition target ... for hwnd 000000000008010E (subclassed, orig_wndproc ...).
dcomp:dcomp_target_SetRoot iface ..., visual ..., target hwnd 000000000008010E.
dcomp:dcomp_visual_SetContent iface ..., content 000000000D261A90 (visual: target_hwnd 000000000008010E).
dcomp:dcomp_visual_try_reparent Reparent skipped: content 0000000000000000, target_hwnd 000000000008010E.
dcomp:dcomp_visual_try_reparent Requested swapchain window switch from 00000000000900F8 to target 000000000008010E.
dcomp:dcomp_visual_try_reparent Switching swapchain window from 00000000000900F8 to target 000000000008010E.

dxgi:dcomp_swapchain_wndproc DComp popup-detect: target 000000000008010E style=0x46000000 parent=0000000000080104 count=0.
dxgi:dcomp_swapchain_wndproc DComp: subclassed target 000000000008010E, orig wndproc ..., timer started, sc=...
dxgi:dcomp_swapchain_wndproc DComp: target 000000000008010E client=1100x720 screen=(0,0)-(1100,720) parent=0000000000080104 sc=1100x720.
dxgi:dcomp_swapchain_wndproc DComp: target 000000000008010E now 1100x720, swapchain switched.
dxgi:dcomp_target_wndproc WM_PAINT #1: hwnd 000000000008010E 1100x720, comp_dc=0000000003410060.
dxgi:dcomp_target_wndproc WM_PAINT #2: hwnd 000000000008010E 1100x720, comp_dc=0000000003410060.
d3d:swapchain_blit_gdi Using GDI present.

Notes on the above:

• The target 0x8010E is not top-level: parent=0x80104, style 0x46000000
  (WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN|WS_CLIPSIBLINGS). yabridge has reparented
  the editor into the host's window before WebView2 creates its composition target.
• One try_reparent call reports Reparent skipped: content 0000000000000000, i.e.
  it ran before SetContent supplied a swapchain.
• Only two WM_PAINT events are ever delivered to the subclassed target; after
  that nothing further presents, even as the page animates.

Ruled out

Tested via the AdditionalBrowserArguments policy key (the
WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS env var is ignored here because JUCE supplies
its own options object), each with a fresh browser process — WebView2 shares one
browser process per user-data-dir and silently ignores argument changes otherwise:

• --disable-features=CalculateNativeWinOcclusion, --disable-backgrounding-occluded-windows,
  --disable-renderer-backgrounding — no change (and visibilityState was already visible)
• --disable-gpu, --disable-gpu-compositing — no change
• --disable-direct-composition — no change; a DComp Swapchain window is still created
• --use-angle=gl / --use-gl=angle — no change (WebGL still reports the D3D11 ANGLE backend)
• --use-angle=swiftshader — WebView2 fails to start entirely
• yabridge editor_double_embed — no change

Hypothesis

The dcomp/dxgi presentation path assumes the composition target is a top-level window
it can subclass and drive via WM_PAINT + GDI blit. When the target is already a
reparented child of a foreign (host) window, the swapchain window switch completes but
the subsequent present/paint cycle does not, so the composed frame is never blitted to
the visible window.

Happy to test patches or gather more traces — this reproduces 100% of the time.

[blakebratcher]

Correction — scope is narrower than originally reported

I've since run a control that contradicts the "reparented child" framing in my
original report. Please disregard that part; the trace and the rest stand.

Control: eclipse 1.8 (JUCE 8.0.12, Direct2DHwndContext) bridged through
the same yabridge into the same prefix/runner renders perfectly — full UI,
text, knobs, spectrum display. It also creates a DComp Swapchain child window and
its target HWND is likewise reparented into the host window.

So JUCE 8 Direct2D/DComp presentation into a yabridge-reparented child window works
fine in general. My conclusion that reparented children never present was wrong.

What actually fails is narrower — WebView2 specifically, i.e. the case where the
composed frame comes from a separate browser process compositing into the plugin's
HWND, rather than the plugin's own in-process D2D swapchain:

plugin	JUCE	UI tech	embedded result
eclipse 1.8	8.0.12	JUCE Direct2D	renders fully
Minimal Audio "Current" 2.2.1	8.0.13	JUCE Direct2D	renders (a couple of image/placeholder elements empty — likely app state, not wine)
Minimal Audio "EPROM - Memory Rites" 1.1.0	8.0.13	JUCE WebBrowserComponent → WebView2	nothing presents

The WebView2 case is still exactly as traced above: DOM complete, WebGL verified
working, visibilityState: visible, Page.captureScreenshot all-black, swapchain
window switch completes, only two WM_PAINTs delivered, then nothing.

Net: this looks like a WebView2/cross-process-composition issue, not a general
child-HWND one. Sorry for the noise in the initial framing — happy to test patches.

[giang17]

Thanks again for the excellent report — and for the eclipse control that narrowed this to WebView2; that isolation was exactly right. I finally got a local reproduction (Minimal Audio EPROM – Memory Rites, same WebView2 Expansion Player), and after working through it I have a clearer, if not more encouraging, picture.

Short version: this is Wine-Core, not anything in this fork's DComp/dxgi work. I'd rather be upfront than string you along.

Locally I see exactly your symptom — editor window black, web content fully alive (DOM complete, WebGL renders, visibilityState: visible, captureScreenshot all-black), plus a crash when closing the editor.

What the traces show:

1. The composed frame never reaches the plugin's HWND. WebView2/Edge renders in its own processes (Manager / Network / Storage / juce.backend); in the plugin's process there are zero CreateSwapChainForComposition/Present/dcomp calls — only CreateDXGIFactory probing. On Windows, DComp marshals that frame cross-process into the plugin's composition target; Wine doesn't implement that cross-process DComp marshalling, so the window never receives the frame → black. Structural gap, fork-independent.
2. Edge runs heavily degraded under Wine — a long string of WinRT/COM activations fail (WebAuthenticationCoreManager, AppCapability, ClosedCaptionProperties, PenDevice, UIViewSettings, …); Wine's WinRT surface is incomplete.
3. Crash on close is a separate Wine-Core ole32 bug: RevokeDragDrop → IDropTarget_Release on an already-freed (non-null dangling) drop-target — ole2.c:639 has the NULL check, but the pointer is stale → use-after-free during teardown.

None of this touches the fork's composition/swapchain code (the path I first suspected — dcomp_target_wndproc/swapchain_blit_gdi — is never entered here). So there's no fork-level fix I can offer for the black window; it needs Wine-Core work (cross-process DComp + WinRT), which is upstream.

The teardown crash is concrete enough to file as a WineHQ bug (reproducer: this plugin + any host + close the editor → crash in ole32's RevokeDragDrop).

[giang17]

Status update (2026-07-24) — my earlier conclusion was too pessimistic

Correcting my comment above: "no fork-level fix I can offer" turned out to be wrong. The trace observation (zero CreateSwapChainForComposition/Present/dcomp calls in the plugin process) was accurate, but the conclusion wasn't: the composed frame lives in WebView2's GPU process, and the fork can composite that process's DComp visual tree onto the plugin's child window itself — no cross-process DComp marshalling needed for this path.

Fixed on the public d2d1-dcomp-11.0 branch

1. Crash on closing the editor — fixed in fafb443f85e (ole32: reject RevokeDragDrop for windows owned by other processes). The browser helper called RevokeDragDrop on the plugin's HWND from its own process; ole32 then released a drop-target pointer that was only valid in the owning process → the use-after-free you traced. RevokeDragDrop now rejects cross-process windows, same as RegisterDragDrop already did.
2. Black editor window — the fork now composites WebView2's GPU-process visual tree into the plugin window: 4e03da8bf4d (composite rootless visual trees onto the target window), 94e8fe91fee (cross-process targets, backdrop capture), 396042c48bb (z-order of reparented comp windows), 45482e44130 (forward WM_PAINT to the original wndproc in full-mode DComp targets — this one fixed "renders once, then freezes on hover/click").

Verified locally with EPROM – Memory Rites 1.1.0 in REAPER under Wine: the main plugin UI renders fully, with artwork, and reacts to input. FL Studio's WebView2 surfaces improved as well.

EPROM – Memory Rites main UI rendering fully under Wine (public d2d1-dcomp-11.0).

Known remaining limitation (work in progress)

With WebView2 Runtime 150.0.4078.x, the initial login/start screen still shows a black background instead of the artwork (a gray panel in the middle is visible). Cause, traced: this Chromium generation promotes page content into delegated compositing after 2–3 frames — the root swapchain then only carries opaque "punch" frames, and the actual content is supposed to flow through IDCompositionTexture / IDCompositionDevice4/5, which Wine doesn't implement. The dcomp side of that (composition textures) is implemented and self-tested on a dev branch; the current blocker is one level lower — Chromium gates the whole path on D3D11 monitored fences (DXGI_ADAPTER_FLAG3_SUPPORT_MONITORED_FENCES + ID3D11Device5::CreateFence), which are stubs in Wine. That's the next work item. The post-login UI is not affected.

Workaround for the login screen: resizing the editor window forces a swapchain reset, and the first frame after each reset renders the full page — so after a resize the login form becomes visible and signing in works. Once signed in, the main UI renders normally without further tricks.

Runtime 150 login screen after the resize workaround: the form renders and logging in works — only the background artwork is still missing (the delegated-compositing gap described above). (The WinRT activation failures from my earlier comment are still there, but they proved to be noise, not the blocker.)

If you'd like to re-test

A build from the current public d2d1-dcomp-11.0 should get you: no crash on close, and a rendering, interactive editor — please mention which WebView2 Evergreen Runtime version your prefix has (C:\Program Files (x86)\Microsoft\EdgeWebView\Application\<version>), since 149 vs 150 behave differently on the login screen. A small resize-flicker improvement (wined3d: copy the full backbuffer when recreating the DComp composition buffer) is queued for the next push to this branch.

[blakebratcher]

Thanks for the deep dig and the fixes — built the current d2d1-dcomp-11.0 (wine-11.0-193-g1d1fa5f9fb5) and tested here.

Setup: yabridge 5.1.1 + Carla (individual host), offscreen X, NVIDIA RTX 3090 (proprietary), EPROM – Memory Rites 1.1.0, unactivated. WebView2 runtimes pinned as fixed-version via WEBVIEW2_BROWSER_EXECUTABLE_FOLDER.

The native-compositing fix works — confirmed. With WebView2 109.0.1518.78, the plugin's native JUCE fallback ("Player UI failed to load…") now renders fully into the reparented editor window. On the old -167 build that exact window was solid gray. So "composite rootless visual trees onto the target window" is landing for native/D2D content in the embedded-yabridge case.

Web content still doesn't present on 149/150 — and I see no 149-vs-150 difference. Under this build:

WebView2	result
109.0.1518.78	native fallback renders (web app too old to load)
149.0.4022.98	web app loads (DOM complete) → only the plugin's gray placeholder presents
150.0.4078.83	pixel-identical to 149 — gray placeholder, no content

149 and 150 gave byte-identical captures here (mean 0.0480, sd 0.1099), so on my setup they behave the same, not differently.

Note this instance is unactivated, but the DOM already contains the full synth UI (preset name, macro labels, KEY/ARP/CHORD — not a login form), so this is the start-screen/delegated-compositing path rather than anything gated behind sign-in.

Questions:

1. Is the IDCompositionTexture + monitored-fences gap the universal blocker for Chromium 149+ here — i.e. nothing short of that work will present these surfaces — or is there a runtime version known to run a modern web app while still avoiding delegated compositing?
2. Your working REAPER capture — was that an activated instance, and do you recall the WebView2 version? Trying to understand why it renders for you but shows the placeholder here on both 149 and 150.

Happy to test the composition-texture dev branch whenever it's ready — this reproduces 100% and I can turn traces around quickly.

[giang17]

Research update (2026-07-27) — why the web layer stays empty: Edge's delegated compositing drops the layer itself, and we can prove the content is recoverable

Since your -193 re-test I've been instrumenting the WebView2 GPU process end-to-end (same EPROM – Memory Rites repro, Runtime 150). The picture is now sharp:

1. The content is rendered every frame — it just never leaves Edge's compositor.
The login artwork is GPU-rasterised continuously (a 1100×1112 render target, draws + atlas samples + copies every frame), but on Wine it is never drawn into the root pass. This is not a stall and not a WebGL failure.

2. The delegated visual tree shows the drop directly.
Edge builds a two-leaf tree: the page-content visual receives real composition swapchains (all CreateSwapChainForComposition calls succeed and composite fine), while the artwork/overlay visual receives SetContent(NULL) from frame 1 onward. Edge even creates the IDCompositionDynamicTexture for exactly that layer — and abandons it immediately: no SetTexture, no fence query, never set as content. (Correction 2026-07-28: source analysis shows this dynamic texture is created unconditionally for the primary plane in the DCLayerTree constructor and stays unused on stock Windows as well — Chromium's BufferQueue feature is disabled by default. No association with this layer, no diagnostic value. See the closing comment below.)

3. A full API census says: no Wine API fails.
Every content-delivery call Edge makes returns success (Device3/4/5 QIs, CheckCompositionTextureSupport → supported, dynamic-texture creation, composition swapchains). The drop is Edge's own decision, taken after a series of capability probes.

4. Proof the frame is recoverable Wine-side.
An (env-gated, experimental) test fix that grabs the rasterised render target and composites it into the plugin window renders the artwork fully — visible and interactive (the depth-parallax shader tracks the mouse). Nothing is lost inside Edge; Wine can reach the pixels.

5. Causal tests: none of the failing Wine APIs is the trigger.
Three gated experiments, each with in-log proof that the changed answer reached Edge: (a) serving the two unknown device QI IIDs ({4ca97a18-…}, {df0c7cec-…}) with a real interface — Edge never even calls into them (pure feature detection, no crash in 30 min), layer still NULL; (b) answering IDXGIOutput::CheckOverlaySupport with DIRECT|SCALING (today it returns E_NOTIMPL and — notably — leaves the out-flags uninitialised, so Chromium decides overlay promotion on undefined data) — the answer is demonstrably consumed (Edge's probing halves and moves one step further to CheckOverlayColorSpaceSupport, another stub of the same shape), but the layer still ends NULL; (c) implementing IDXGIDevice::EnqueueSetEvent signalling — zero structural difference. The Wine-API trail is exhausted.

6. The NULL overlay visual is benign in itself.
The plugin's main window (after activation) builds a structurally identical visual tree — same NULL overlay visual, same content swapchain — and renders completely. So the failure is specific to how the backdrop-filter/WebGL panel is routed on the login screen, not a general DComp/swapchain break.

Where this goes: the path forward is productising the Wine-side composite of that dropped layer (the approach proven in point 4): robust identification of the panel render target, placement from the visual tree, and a preserved card layer above it so page UI and artwork show together. That work is in progress on a probe branch; nothing new to build/test on the public branch yet. I'll follow up here once it lands on d2d1-dcomp-11.0 — that will be worth a re-test in your yabridge/Carla setup, where the same delegation gap plausibly hits the page layer too. (Superseded 2026-07-28: the productization could not reach a stable page-UI capture after six iteration rounds and the Wine-side line is now closed — see the closing comment below.)

[giang17]

Belated answers to your two questions from the re-test comment — the research update above covered the "what", these are the "so what":

1. Is the IDCompositionTexture + monitored-fences gap the universal blocker for 149+?
No — the newer instrumentation says that chain is not the blocker at all. Edge probes CheckCompositionTextureSupport (we report supported), creates exactly one IDCompositionDynamicTexture — and abandons it unused; content is never routed through that path. Page content arrives exclusively as composition swapchains (which succeed end-to-end), and the missing layer is dropped by Edge's own compositor decision — three gated causal experiments (serving the two unknown QI IIDs, answering CheckOverlaySupport with real flags, implementing EnqueueSetEvent) changed nothing. So finishing the composition-texture/fences work would not, by itself, make these surfaces present. And I don't know of any runtime that loads the modern web app while avoiding delegated compositing — your "149 and 150 are pixel-identical" finding matches our measurements exactly.

2. Was the working REAPER capture an activated instance, and which WebView2 version?
Activated, evergreen 150.0.4078.96. But activation is not the differentiator: an unactivated instance here presents the page content too — visually that's the GET STARTED card (which, matching your "not a login form" DOM observation, has no credential fields; the actual sign-in page only appears after clicking "Activate with Minimal Audio"). Your DOM note that the full synth UI is already loaded while unactivated is a useful data point in itself — we can't inspect the DOM here (CDP is unavailable for JUCE-embedded WebView2), so it tells us the app preloads the whole UI behind the start gate. Either way: the same start-screen state presents here over the same swapchain path that shows you only the placeholder — which points away from content/activation state and toward the presentation path in your host setup.

First, the cheapest check — resize the editor window. On this fork build, the documented behaviour of the start screen in our REAPER repro is: gray placeholder at rest, content (text + buttons) appears only after resizing the window — and vanishes again after a click, until the next resize. The mechanism: Chromium delivers a full page frame only as frame 1 of each swapchain generation (a resize forces one); at rest it re-presents only punch-black frames. Your captures read exactly like our pre-resize state, and I can't tell from the thread whether the editor window ever got resized in your offscreen setup. So: with the placeholder showing, resize the editor window (host-side, e.g. xdotool on the top-level, or Carla's window) and capture right after — if the start-screen text flashes in, your setup behaves identically to ours and everything below is confirmation rather than diagnosis.

If resize changes nothing, two discriminating checks:

1. xwininfo -root -tree | grep -iE "chrome_widget|intermediate d3d" — in the REAPER repro Chromium deliberately parks that whole chain at x = n × host-client-width (one or two window-widths right of the host); Wine's visible-region calculation then clips the fork's composite blit to nothing. If those windows sit at large x offsets relative to the editor window, that's the parking.
2. A WINEDEBUG=+fixme log, grepped for Composited visual tree — that line prints continuously when the fork's tree compositing is actually running in your plugin process; its absence (or presence with a clip that never lands) narrows things a lot.

If parking is what you see, we have a preventive fix for exactly that (clamping the parked position in win32u's set_window_pos; env-gated prototype, not yet on the public branch) — your trace would be the justification to promote it. One expectation-setter for when presentation does start working: there is a separate, known issue where content vanishes after clicks until the window is resized (Chromium re-presents only punch frames after interaction; a resize forces a full frame). So "shows content, but clicks blank it" would be that pre-existing line, not a regression of the presentation fix. Either way: thanks for the standing offer to test, that turnaround is exactly what this needs. The overlay/artwork productization continues separately and I'll ping you for a re-test once it lands. (Superseded 2026-07-28: the productization is stopped — see the closing comment below.)

[giang17]

Status update (2026-07-28) — the Wine-side line is closed; root cause pinned in Edge's delegated compositing

Follow-up work since the research update — a fourth causal test, a source-level analysis of Chromium's DCLayerTree/overlay path verified against our measurements, and several gated fix experiments — has closed the investigation on the Wine side. I've marked the two superseded statements in my comments above; here is what the completed analysis established, condensed:

• The stationary punch-black root swapchain is correct behaviour, not the defect. Windows' default delegation mode is kLimitToUi: the root pass punches holes for delegated content by design. The defect is that the content behind those holes never arrives.
• The delegated layers' damage is kept private by Edge's compositor. Measured consequence: the content swapchain presents exactly once per buffer generation and then goes silent — and that first frame is the only one carrying the full page. This is precisely why the resize workaround works: a resize forces a new generation, hence one full frame, which the fork's composition surface then preserves on screen.
• Window messages cannot trigger that path. Gated experiments with RedrawWindow/WM_PAINT (Chromium paints independently of it) and WM_DISPLAYCHANGE (produces recomposition activity, but all frames empty) both failed; only a real bounds change reaches the ResizeBuffers → new-generation path. A periodic resize-jiggle would work mechanically but is visually unacceptable — rejected.
• The Wine-API trail is exhausted in both directions. A fourth causal test (serving CheckOverlayColorSpaceSupport) changed nothing, completing the earlier three; and the reverse direction — an honest capability downgrade (CheckCompositionTextureSupport → unsupported, monitored-fences flag dropped) — is equally ignored: Edge does not consult these answers for its delegation decision.
• No Wine-triggerable failure path can even produce the observed picture. In Chromium's code, every runtime failure in the overlay-image chain ends as a white placeholder or a dropped layer — never as the persistent empty visual we measure. The empty layer is Edge's own construction, decided before any dcomp/dxgi contact.

Where this leaves things: the 2026-07-24 state of the public branch remains the best available — main plugin UI renders fully and interactively; the login screen needs the one-time resize workaround (now with a mechanical explanation rather than folklore). The remaining fix level is the app/runtime side — how Edge's delegated compositing sources content for these layers under Wine. The full analysis in this thread is public for anyone upstream (WineHQ, Chromium/Edge, or the plugin vendor) to pick up; I'll of course follow up if a runtime or app update changes the picture.

[giang17]

Follow-up (2026-08): Wine-side analysis now measured at two chokepoints; a Windows reference run would settle it

Following up on the 2026-07-28 wrap-up ("Wine side closed, fix level is
app/runtime"). Since then that conclusion has been verified by direct
measurement at the two points that decide whether the artwork/login content ever
reaches the screen — narrowing where a fix could ever come from, and leaving a
single question that only a native-Windows reference run can answer.

Two instrumented measurements (August 2026)

• Content-swapchain Present: in idle the content swapchain presents ~0 times
  after frame 1; under a resize it presents 2-3×, but every frame is
  empty (black, ~0% bright). Present-timing is not the lever — pushing the app
  to present more doesn't help.
• Overlay-visual SetContent: the overlay visual that should carry the artwork
  gets SetContent(NULL); the IDCompositionDynamicTexture that Edge creates for
  the backdrop-filter layer is never assigned to any visual. The artwork reaches
  DirectComposition on no path.

Both were checked across the host process and the msedgewebview2 GPU process
(the one that actually makes the composition calls), so "we measured the wrong
process" is ruled out. This turns the July inference — "Edge's delegated-compositing
decision drops the layer before any dcomp/dxgi contact" — into a counted fact: the
layer is created and the swapchain is presented, but the content is never composed
into the back buffer or assigned to the overlay visual. There is no Wine API a fix
could target.

The fork only a Windows reference measurement can settle

The one thing Chromium main can't answer here (Edge 149/150 diverges from main on
this code path): does the overlay visual get a real content on native Windows?

• Windows assigns a content → there is a Wine-side content-transfer bug we
  haven't found — a concrete lever to chase.
• Windows is also empty via dcomp → on Windows the artwork reaches the screen
  through a different path (e.g. composited directly into the WebContents
  swapchain rather than a dcomp overlay), and the dcomp-overlay angle is a dead end.

If anyone with a Windows setup and EPROM (or even Edge + a backdrop-filter test
page) can run one measurement, it would resolve this:

1. API Monitor (rohitab.com, free) attached to the msedgewebview2 GPU process,
   logging IDCompositionVisual::SetContent — does the overlay visual get a
   non-NULL content? (This is the direct native equivalent of the second measurement
   above.)
2. PIX or RenderDoc GPU capture — inspect the dcomp visual tree and the
   content swapchain: does the overlay visual carry artwork, and is the content
   swapchain non-black in idle?

I don't have a Windows measurement setup myself. @blakebratcher — if you (or
anyone watching) have access and are inclined to try, that single result would
either reopen this with a concrete Wine bug to fix, or close the dcomp-overlay
angle for good. Happy to write up the exact API-Monitor filter set or PIX
workflow if useful.

[giang17]

Root cause found, and it is not the reparented child window — it is JUCE.

What actually happens

JUCE 8.0.13 (upstream commit 5179690ff7,
"Restore Wine functionality") switches the renderer to GDI whenever it detects Wine:

// 8.0.11, 8.0.12:
return new HWNDComponentPeer { *this, styleFlags, (HWND) parentHWND, false, 1 };
// 8.0.13, 8.0.14, 8.0.15:
const auto renderer = juce_isRunningInWine() ? 0 : 1;

The index selects from contextDescriptorList<GDIRenderContext, D2DRenderContext>, so 0 is
GDI. Detection is GetProcAddress(GetModuleHandleA("ntdll"), "wine_get_version") != nullptr,
which is true on any Wine build, patched or not.

EPROM - Memory Rites has been JUCE 8.0.13 since its June build. So on the version you tested,
the plugin's peer never had a composition swapchain in the first place — and Chromium, embedded
into that window, had nothing to present into. That is why the frame "never reaches the target
window" no matter what the compositing path does.

It also explains your control cleanly: a top-level Tauri app renders because it isn't JUCE and
never takes that fallback. The distinguishing factor was never top-level vs. reparented — it was
JUCE vs. not-JUCE.

Proof

With JUCE forced back onto Direct2D, the editor renders completely — login splash with its full
artwork, and after logging in the account screen with artwork and icons:

The same run before the change shows the plugin's placeholder background only, exactly as you
described. Beyond the artwork, this also removed the flicker, the "content only appears after a
resize" behaviour, and made clicks on the login page work again — a whole family of symptoms we
had been tracking as separate problems.

For scale, measured on a JUCE 8.0.13 plugin with WINEDEBUG=+d2d: 23 d2d1 calls with the
fallback active (factory and device creation only, not a single d2d_device_context_*, i.e.
nothing is drawn through Direct2D), versus 2,653,764 with it disabled, along with a
composition swapchain window that does not otherwise exist.

I should add that this cost us weeks of misdirected work. We instrumented SetContent, measured
dynamic_count=0, established a permanently punch-black root leaf, and ran thirteen causal
tests — all correctly measured, all describing a pipeline the plugin no longer entered. Every
Wine-side lever was inert for exactly that reason.

How to test

d2d1-dcomp-11.0 now hides that single export from GetProcAddress, so JUCE takes the Direct2D
path again — commit 3285e13505e, documented in PATCHES.md. It is opt-in — enable it for the host that runs the plug-in:

HKCU\Software\Wine\AppDefaults\<host.exe>\HideWineVersion = "Y"

or WINE_HIDE_WINE_VERSION=1 for a single run. Pull,
rebuild, and the editor should come up with content, including through yabridge.

For an A/B on the same binary, WINE_HIDE_WINE_VERSION=0 restores the old behaviour for a
single run.

One caveat before it bites you: the switch is process-wide, so anything else probing for Wine
stops finding it. PACE/iLok protected software refuses to start as a result (Error 2000, pointing at iLok rather
than at Wine), and Ableton Live's embedded Splice view stops loading. That is why it defaults to
off and is meant to be enabled per host rather than system-wide.

An upstream fix is proposed as juce-framework/JUCE#1701, which adds the
same opt-in inside JUCE and would make this workaround unnecessary.

Your report, and the CDP evidence in it showing the DOM fully alive while the composed frame
never arrived, is what kept this on the presentation side rather than the content side. That was
the correct call — we were simply looking at the wrong presentation path.

[giang17]

Closing as completed — root cause and fix landed via issue 11.

The "DComp swapchain never presents when the target HWND is a reparented child" framing
turned out to be this same JUCE 8.0.13 GDI fallback wearing a different costume: with the
fallback active, the plugin's peer never had a composition swapchain at all, so Chromium had
nothing to present into. The reparenting was never the distinguishing factor — your top-level
Tauri control worked because it isn't JUCE.

Confirmed on your rig in issue 11 (issuecomment-5256404509): with
WINE_HIDE_WINE_VERSION=1 on 3285e13505e, EPROM's full start screen presents at rest —
artwork included, no resize workaround, WebView2 fixed-version 150.0.4078.83, embedded
through yabridge as in the original report here.

The switch is opt-in and documented in PATCHES.md; the upstream fix proposal is
juce-framework/JUCE#1701.