Weld Chromium Embedded Framework rendered output into wgpu-importable GPU textures via CEF's accelerated off-screen rendering (OSR).

This repo was created as a sibling to wgpu-graft (Servo testbed, GL-FBO / Vulkan / Metal / D3D interop) and wgpu-scry (system-webview frame adapter — WebView2 / WKWebView / WebKitGTK).

wgpu-weld covers the CEF side: rather than using the OS's built-in webview, the embedder bundles Chromium and routes CEF's OnAcceleratedPaint output into host-owned wgpu textures. CEF hands out callback-scoped native handles, so the core rule is "copy or retain inside the paint callback, then expose only an owned resource to the host side." The trade-off is binary size and a more complex process model (see CEF Foibles in the welding crate docs) in exchange for a single cross-platform producer, uniform browser behaviour, and direct access to the CEF DevTools protocol.

See welding/README.md for the producer/consumer contract and the platform texture paths.

# cargo check does not require CEF_PATH; runtime initialization does.
set CEF_PATH=C:\path\to\cef_binary_147.x_windows64

cargo check -p welding
cargo run -p demo-weld-win

For a deterministic visual smoke test, point the demo at a data URL with WELD_URL; otherwise it loads https://example.com.

All three repos are structurally derived from the same pattern — native GPU surface handles produced by an embedded browser, imported into a host wgpu pipeline — but serve different niches:

wgpu-weld ships the engine; wgpu-scry uses the OS's. CEF's single cross-platform producer means one implementation family to maintain, and OnAcceleratedPaint gives a more direct texture source than WGC capture. The hard part moves to CEF's C ABI/vtable ownership and callback-scoped handle lifetime.

MPL-2.0