BloomView: implement live rendering on all platforms (macOS, iOS, GTK4/Linux, Android, visionOS, tvOS/watchOS)

[proggeramlug]

Follow-up to #2395 (BloomView) / #5518.

Current state

BloomView now links and creates a real native render-surface view on every target (#5518): a child HWND on Windows, an NSView/UIView on macOS/iOS/visionOS, a GtkDrawingArea on GTK4, an android.view.View on Android (tvOS/watchOS are link-stability stubs). bloomViewGetHwnd(view) returns the platform's native handle.

But live rendering only works on Windows. The Bloom engine can only build its surface on an HWND (bloom_attach_hwnd, Bloom-Engine/engine#70). On the other platforms the view is created and a handle is handed out, but no renderer attaches to it yet.

Goal

Make a BloomView actually render a Bloom scene on every platform Bloom supports, not just Windows.

Work breakdown

Engine side (Bloom-Engine/engine) — ✅ landed in Bloom-Engine/engine#71

The engine exposes one platform-neutral ABI symbol bloom_attach_native(handle, w, h) (each platform interprets handle as its own NSView*/UIView*/ANativeWindow*/HWND) rather than distinct bloom_attach_nsview/uiview/surface names — the function manifest is shared and CI requires every platform to export every entry, so one symbol beats N stubs. A shared attach_engine() helper factors the wgpu bring-up out of every bloom_init_window (macOS was refactored onto it). TS exposes the named wrappers attachToNSView / attachToUIView / attachToSurface + attachToNativeView. Also added real cross-platform bloom_resize. Verified: macOS renders a scene end-to-end headless; iOS cross-compiles.

• macOS — host-NSView Metal attach.
• iOS / visionOS / tvOS — host-UIView Metal attach.
• Linux/GTK4 — Codegen emits dangling LLVM metadata reference (!alias.scope !201) — blocks multi-module compile #71 ships a documented stub returning failure; the real GtkWidget→GdkSurface (X11/Wayland or GtkGLArea) bridge is still TODO.
• Android — host-ANativeWindow attach (needs the Perry-side SurfaceView switch below to produce the window).
• TS wrappers + package.json function-manifest entries.

Perry UI side (PerryTS/perry)

• Sizing: BloomView reserves a fixed size on Windows; the other backends create the view but don't yet apply the requested dimensions. Wire size via Auto Layout (Apple), set_size_request is done for GTK4, LayoutParams (Android).
• Android: switch the widget from android.view.View to a SurfaceView/TextureView and expose its Surface (currently bloomViewGetHwnd echoes the registry token).
• tvOS / watchOS: promote from stubs to real views if Bloom targets them (watchOS likely stays a stub).
• Input / focus routing per platform (Windows subclasses the HWND for keyboard/mouse; Apple/GTK/Android need their own).
• Per-platform demo + verification: extend embed-perry/ (feat(windows): embed Bloom in a host window via bloom_attach_hwnd (Perry UI BloomView, #2395) Bloom-Engine/engine#70) with a build per target, and confirm a live scene renders inside a Perry UI app on each.

Naming

• Consider renaming the Windows-centric bloomViewGetHwnd to a platform-neutral bloomViewGetNativeHandle (with a deprecated alias) now that it returns NSView*/UIView*/GtkWidget*/etc.

References

• Origin: Bloom engine integration with Perry UI #2395
• Perry-side widget (all platforms link; Windows renders): feat(ui): BloomView — embed the Bloom engine in a Perry UI app (#2395) #5518
• Engine-side Windows attach: feat(windows): embed Bloom in a host window via bloom_attach_hwnd (Perry UI BloomView, #2395) Bloom-Engine/engine#70
• Engine-side all-platform attach (bloom_attach_native): feat(attach): host-surface attach path on all platforms (PerryTS/perry#5519) Bloom-Engine/engine#71 ✅ merged

[proggeramlug]

Engine side done — Bloom-Engine/engine#71 merged. The engine now attaches to a host-provided surface on macOS/iOS/tvOS/visionOS/Android via bloom_attach_native(handle, w, h), plus real cross-platform bloom_resize. macOS verified rendering end-to-end; iOS cross-compiles.

Remaining Perry-UI side (this repo)

Perry UI stays Bloom-agnostic (it only owns the view + hands out the native handle; user TS calls the engine's attachToNSView/etc.). So the work is making the handed-out handle actually usable per platform:

1. Rename bloomViewGetHwnd → bloomViewGetNativeHandle (keep bloomViewGetHwnd as a deprecated alias) — dispatch table + api-manifest + docs. Platform-neutral now that it returns NSView*/UIView*/ANativeWindow*/HWND.
2. Sizing — macОS/iOS create the view but ignore the requested width/height (the NSView/UIView gets no frame → zero-size surface). Apply size via Auto Layout (Apple) / LayoutParams (Android). GTK4 already does set_size_request; Windows already reserves fixed size.
3. Android — switch the widget from android.view.View to a SurfaceView/TextureView and return its ANativeWindow from bloomViewGetNativeHandle (currently echoes the registry token), so the engine's Android attach has a real window.
4. Input / focus routing on Apple/GTK/Android (Windows already subclasses the HWND).
5. Demo + verification — a small Perry UI app embedding a BloomView and calling attachToNSView, confirming a live scene renders.

Plan: land #1 (rename) + #2 (macOS sizing) first as a verifiable slice on this Mac, then iterate per platform.

[proggeramlug]

Perry-UI side up: #5538 (green — lint / cargo-test / api-docs-drift / compiler-output-regression / security-audit all pass).

Covers the whole Perry-side checklist:

• ✅ Rename bloomViewGetHwnd → bloomViewGetNativeHandle (+ deprecated alias).
• ✅ Sizing on macOS/iOS/visionOS/tvOS (Auto Layout) + Android (LayoutParams); GTK/Windows already did. This was the actual blocker for non-Windows rendering — the views were coming up 0×0.
• ✅ tvOS stub → real UIView.
• ✅ Android View → SurfaceView, bloomViewGetNativeHandle returns a real ANativeWindow* (ANativeWindow_fromSurface).
• ✅ Input/focus: host views are now focusable (macOS acceptsFirstResponder subclass; iOS/tvOS/visionOS userInteractionEnabled; GTK set_focusable; Android setFocusable).
• ✅ Demo: examples/bloomview_embed_demo.ts — verified on macOS the integrated Perry-UI-+-Bloom binary links and runs the attach/frame loop.

Remaining (tracked, not blocking): full keyboard/mouse event forwarding into the engine (engine's job once attached, as Bloom subclasses the host wndproc on Windows); Android surfaceCreated deferral; real GTK4 GdkSurface bridge (#71 ships a stub). Once #5538 merges the macOS/iOS path is end-to-end.