feat(windows): embed Bloom in a host window via bloom_attach_hwnd (Perry UI BloomView, #2395)#70
Merged
Merged
Conversation
…rry UI BloomView, #2395) Lets Bloom render into a host-provided child window instead of always creating its own top-level window — the engine side of the Perry UI `BloomView` widget (PerryTS/perry#5518), analogous to Flame inside Flutter. - native/windows/src/lib.rs: factor the wgpu surface + engine init out of bloom_init_window into init_engine_for_hwnd, shared with a new FFI bloom_attach_hwnd(hwnd, w, h). It builds the surface on the host HWND and classic-subclasses it (WM_SIZE/keyboard/mouse → engine). Add bloom_resize, an EMBEDDED flag (begin_drawing skips its own message pump; should_close reports "stay open" since the host owns the loop). - src/core/index.ts: attachToHwnd / resize TS wrappers (+ src/index.ts export). - package.json: declare bloom_attach_hwnd / bloom_resize in the native-library function manifest. - embed-perry/: a demo Perry UI app embedding a live Bloom 3D scene (requires the BloomView Perry build from PerryTS/perry#5518 to compile/run). Windows only for now; per-platform attach (NSView/UIView/dmabuf) is a follow-up.
proggeramlug
added a commit
that referenced
this pull request
Jun 22, 2026
The ffi-parity check was already red on main (29 failures): #69 added the mesh-scratch / tonemap / bloom-intensity / auto-exposure FFI functions and #70 added bloom_attach_hwnd / bloom_resize to the shared manifest, but neither was exported (or allowlisted) on the platforms that don't pick them up automatically. The manifest contract requires every platform to export every entry, so the attach PR can't go green without closing them. - bloom_resize: real on macOS/iOS/tvOS/visionOS/Android/Linux — it just forwards to the shared Renderer::resize (same body as the Windows impl from #70), so host-driven BloomView resizing now works on every target, not only Windows. - bloom_attach_hwnd: no-op stub on the non-Windows native platforms (it's HWND-specific; those hosts use bloom_attach_native). Mirrors #70's own cfg(not(windows)) no-op. - watchos: regenerated ffi_stubs.rs covers the new entries. - web: documented the genuinely-unimplemented entries in tools/validate-ffi.js WEB_GAP_ALLOWLIST (pointer-taking mesh scratch = same WASM linear-memory TODO as bloom_scene_set_lod; post-FX controls not yet wired in the web crate; attach_hwnd N/A on canvas). validate-ffi now passes 0 failures / 0 warnings across all 8 platforms. macOS rebuilds + renders a scene end-to-end; iOS cross-compiles.
proggeramlug
added a commit
that referenced
this pull request
Jun 22, 2026
…y#5519) (#71) * feat(attach): host-surface attach path on all platforms (PerryTS/perry#5519) Add a per-platform "attach to a host-provided surface" entry point so a BloomView (Perry UI) can hand the engine a native view/window/surface it already owns, instead of the engine creating its own window. Previously only Windows could embed (via the engine#70 bloom_attach_hwnd work); every other target created a view but no renderer attached to it. Engine - native/shared/src/attach.rs: factor the wgpu bring-up — instance → surface → adapter → device → swapchain → Renderer → EngineState — duplicated in every platform's bloom_init_window into one attach_engine() helper, parameterised by backend bitmask, dimensions (logical + physical for HiDPI), and a FormatPreference (Srgb / NonSrgb / First) covering each platform's swapchain-format policy. Returns a Result instead of panicking so a host attaching to a not-yet-realized view can recover. - One unified ABI symbol bloom_attach_native(handle, w, h) -> f64 rather than distinct per-platform names: the function manifest is shared and validate-ffi requires every platform to export every entry, so a single symbol (each platform interpreting `handle` as its own view/window/surface pointer) is cleaner than N stubs. TS exposes the named wrappers attachToNSView / attachToUIView / attachToSurface + attachToNativeView, all forwarding to it. - macOS: bloom_init_window refactored to use attach_engine (proves the factoring) + real bloom_attach_native on a host NSView. - iOS / tvOS / visionOS: real attach on a host UIView (tvOS/visionOS use a non-sRGB swapchain to match their windowed path). - Android: real attach on a host ANativeWindow. - Windows: real attach on a host HWND. - Linux: documented stub returning 0 — GTK4 GtkWidget→GdkSurface bridging is the larger follow-up the issue calls out. - watchOS: regenerated no-op stub (no wgpu). web: wasm_bindgen no-op (web builds its surface from the canvas id). - package.json manifest entry; validate-ffi passes 0/0 across all 8 platforms. Verification - shared compiles (native + wasm32); macОS builds and renders a scene end-to-end headless (getScreenWidth/Height read back 320x240 from the attached EngineState, 30 frames, clean exit); iOS cross-compiles; web wasm32 checks. Android/Linux/Windows cross-builds blocked locally by missing C cross-toolchains (NDK / linux-gcc / MSVC), not by this code. * chore(ffi): close pre-existing ffi-parity gaps so CI is green The ffi-parity check was already red on main (29 failures): #69 added the mesh-scratch / tonemap / bloom-intensity / auto-exposure FFI functions and #70 added bloom_attach_hwnd / bloom_resize to the shared manifest, but neither was exported (or allowlisted) on the platforms that don't pick them up automatically. The manifest contract requires every platform to export every entry, so the attach PR can't go green without closing them. - bloom_resize: real on macOS/iOS/tvOS/visionOS/Android/Linux — it just forwards to the shared Renderer::resize (same body as the Windows impl from #70), so host-driven BloomView resizing now works on every target, not only Windows. - bloom_attach_hwnd: no-op stub on the non-Windows native platforms (it's HWND-specific; those hosts use bloom_attach_native). Mirrors #70's own cfg(not(windows)) no-op. - watchos: regenerated ffi_stubs.rs covers the new entries. - web: documented the genuinely-unimplemented entries in tools/validate-ffi.js WEB_GAP_ALLOWLIST (pointer-taking mesh scratch = same WASM linear-memory TODO as bloom_scene_set_lod; post-FX controls not yet wired in the web crate; attach_hwnd N/A on canvas). validate-ffi now passes 0 failures / 0 warnings across all 8 platforms. macOS rebuilds + renders a scene end-to-end; iOS cross-compiles. * chore(ci): grandfather renderer/mod.rs at 11985 lines (#69 growth) renderer/mod.rs grew to 11985 lines in #69 (clouds / foliage wind / additive fog / immediate-mode shadows) but the ratcheting file-lines baseline was left at 11775, leaving check-file-lines red on main. Record the new grandfathered size so the gate is green; the baseline still only ratchets down from here. No code change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The engine side of the Perry UI
BloomViewwidget (PerryTS/perry#5518) — lets Bloom render into a host-provided window instead of always creating its own top-level window, so it can live as a render view inside a normal Perry UI app (analogous to Flame inside Flutter). Pairs with perry-issue #2395.Changes
native/windows/src/lib.rs: factor the wgpu surface + engine init out ofbloom_init_windowintoinit_engine_for_hwnd, shared with a new FFI:bloom_attach_hwnd(hwnd, w, h)— build the surface on a host-provided HWND and classic-subclass it so Bloom still seesWM_SIZE/ keyboard / mouse (its own wndproc never runs for a foreign-class window), then chain to the original proc.bloom_resize(physW, physH, logW, logH)— explicit resize.EMBEDDEDflag:bloom_begin_drawingskips its own message pump (the host owns the loop) andbloom_window_should_closereports "stay open".src/core/index.ts:attachToHwnd/resizeTS wrappers (re-exported fromsrc/index.ts).package.json: declarebloom_attach_hwnd/bloom_resizein the native-library function manifest so Perry links them.embed-perry/: a demo Perry UI app that embeds a live Bloom 3D scene.Usage
The host owns the message loop, so drive frames yourself (don't call
runGame, which blocks).Status
BloomViewwidget already links on all targets.embed-perry/demo compiles and renders a live, animating 3D scene inside a Perry UI window, including resize (seeembed-perry/bloomFull.png).BloomViewPerry build from feat(ui): BloomView — embed the Bloom engine in a Perry UI app (#2395) PerryTS/perry#5518 to compile/run.🔗 Perry-side PR: PerryTS/perry#5518