Extend selective per-pixel transparency (DComp) to floating mode

[dvalfrid]

Floating mode renders one separate OS viewport per visible panel (show_viewport_immediate). Attempted 2026-08-21: applying win_opacity::set_no_redirection_bitmap to a floating panel's HWND renders it as a washed-out light gray/blue instead of the intended translucent panel, even with zero opacity/transparency logic in the drawn content (isolated via controlled tests - not a WS_EX_LAYERED conflict, not a premultiply bug). Points to a real eframe 0.34.3/egui-wgpu limitation in how the swap-chain surface is created for non-root show_viewport_immediate viewports combined with a DComp (DxgiFromVisual) backend. Reverted; floating panels keep the old WS_EX_LAYERED uniform-dim opacity, unaffected. Needs its own dedicated investigation before retrying - see issue comments.

Status: Blocked - eframe/egui-wgpu secondary-viewport DComp limitation, needs dedicated investigation
Source: ROADMAP.md

[dvalfrid]

Investigation results (2026-08-21)

Attempted the same technique as #101 (force DX12 + Dx12SwapchainKind::DxgiFromVisual, apply WS_EX_NOREDIRECTIONBITMAP once per panel HWND via win_opacity::set_no_redirection_bitmap, thread real opacity into panel content, transparent CentralPanel fill). Result: floating panels rendered as a washed-out light gray/blue (RGB 224,233,245) instead of the intended translucent dark panel — not just "still opaque," actively broken.

Isolated the cause via two controlled tests (each panel is a separate show_viewport_immediate OS window, unlike the main window's single root viewport):

• Test 1: applied set_no_redirection_bitmap while also leaving the old per-frame win_opacity::set_opacity (WS_EX_LAYERED) call active. Result: medium gray (109,113,119). Hypothesis: WS_EX_LAYERED and WS_EX_NOREDIRECTIONBITMAP conflict (the former needs the redirection bitmap DWM composites via SetLayeredWindowAttributes; the latter tells DWM not to allocate one).
• Test 2: removed the WS_EX_LAYERED call entirely (no conflict), kept panel content fully opaque (hardcoded 1.0, no premultiply/opacity logic touched at all). Result: still washed out (217,227,238), nearly identical to the original broken result.

Test 2 is the key finding: WS_EX_NOREDIRECTIONBITMAP alone, applied to a secondary show_viewport_immediate viewport, breaks its rendering — even with zero custom opacity/transparency logic in the drawn content. This rules out a mistake in the opacity-threading approach itself (which is exactly what #101 already proved correct for the main/root viewport) and points to a real limitation in how eframe 0.34.3 / egui-wgpu 0.34.3 create or configure the swap-chain surface for non-root immediate viewports when combined with a DComp-composited (DxgiFromVisual) backend — plausibly the composition visual/target isn't being correctly bound per-secondary-viewport-HWND the way it is for the single root Painter.

Conclusion: not a quick follow-on from #101. Reverted all floating-mode changes; floating mode is unaffected and keeps its existing WS_EX_LAYERED uniform-dim behavior. Needs a dedicated investigation (own spike, same rigor as #131) into eframe/egui-wgpu's secondary-viewport surface creation before attempting this again — possibly requiring an eframe source patch, or concluding it's not feasible without one (a documented dead-end is an acceptable outcome here, same as #131's own acceptance criteria).

[dvalfrid]

Root cause found upstream (2026-08-21)

This is a known, already-tracked bug in emilk/egui itself, not specific to how this app uses eframe:

• egui#3632 — open since ~Feb 2025. Multiple independent reporters confirm the same symptom on Windows: the root viewport respects .with_transparent(true), secondary/child viewports (created via show_viewport_immediate/show_viewport_deferred) do not, on both rendering backends (glow and wgpu), for different underlying reasons per backend.
• wgpu backend (what this app uses): PR #8116 (Closes #3632 #7543) — draft/WIP, stalled since 2026-05-08. Adds a configure_wgpu_window_attributes hook that applies WS_EX_NOREDIRECTIONBITMAP at window-creation time for both root and secondary viewports (today it only happens implicitly for the root), plus an adapter-selection fix so the chosen wgpu adapter actually supports the transparent alpha mode for a given surface. This lines up exactly with what we found empirically: applying the style after creation (which works for the root, per Background-only transparency (per-pixel alpha) #101) does not work for secondary viewports.
• Sibling PR #8423 (glow backend, Closes #3632 #7543) is far more active — created 2026-08-15, approved by the maintainer, mergeable. Doesn't fix our (wgpu) case directly, but shows the area has renewed maintainer attention right now.

Decision: wait for the upstream fix rather than hand-rolling a workaround or patching in the WIP branch (explicitly marked "not ready" by its own author). A weekly automated check (Claude Code routine, Mondays 08:00 UTC) watches egui#3632/#8116 and will comment here + on #170 if the upstream state changes (merged, closed, or shipped in a release). Revisit this issue and #170 once that fix lands in a released eframe/egui-wgpu version.