Question: FemtoVG WGPU Renderer on wasm32-unknown-unknown

[xsxun]

Background

We have a downstream experimental project that requires building Slint for wasm32-unknown-unknown with the renderer-femtovg-wgpu and unstable-wgpu-28 features enabled. However, the current codebase has feature gates that explicitly exclude target_family = "wasm" from the WGPU FemtoVG renderer path, preventing compilation.

Current Status

The existing code contains several feature gates that prevent WGPU-based FemtoVG rendering on WebAssembly:

1. internal/backends/winit/renderer/femtovg.rs:

   #[cfg(all(feature = "renderer-femtovg-wgpu", not(target_family = "wasm")))]
   pub struct WGPUFemtoVGRenderer { ... }

2. internal/renderers/femtovg/images.rs:

   #[cfg(all(feature = "wgpu-28", not(target_family = "wasm")))]
   impl TextureImporter for femtovg::renderer::WGPURenderer { ... }

3. internal/renderers/femtovg/images.rs:

   #[cfg(all(not(target_arch = "wasm32"), feature = "unstable-wgpu-28"))]
   ImageInner::WGPUTexture(...)

Changes We Tried

To unblock our downstream project, we experimentally modified the feature gates. These changes work for our specific use case, but we want to understand if they align with Slint's architecture and roadmap:

1. Remove wasm exclusion from WGPUFemtoVGRenderer (femtovg.rs)

-#[cfg(all(feature = "renderer-femtovg-wgpu", not(target_family = "wasm")))]
+#[cfg(feature = "renderer-femtovg-wgpu")]
 pub struct WGPUFemtoVGRenderer {

2. Enable WGPU texture import on wasm (images.rs)

-#[cfg(all(feature = "wgpu-28", not(target_family = "wasm")))]
+#[cfg(feature = "wgpu-28")]
 impl TextureImporter for femtovg::renderer::WGPURenderer {
+    #[cfg(not(target_family = "wasm"))]
     fn convert_opengl_texture(...) -> Self::NativeTexture {

-#[cfg(all(not(target_arch = "wasm32"), feature = "unstable-wgpu-28"))]
+#[cfg(feature = "unstable-wgpu-28")]
 ImageInner::WGPUTexture(i_slint_core::graphics::WGPUTexture::WGPU28Texture(texture))

3. Early return for wasm in adapter detection (wgpu_28.rs)

 Some(RequestedGraphicsAPI::WGPU28(api::WGPUConfiguration::Manual { instance, .. })) => {
+    if cfg!(target_family = "wasm") {
+        return true;
+    }
     (instance, wgpu::Backends::all())
 }

Analysis and Concerns

What Works

1. Texture interop: The WGPU texture import path (ImageInner::WGPUTexture) now compiles and can work on wasm when textures are provided externally
2. Compilation gates: Feature gates no longer block wasm target builds
3. Practical rendering: Our downstream use case (with specific configurations) renders successfully

Potential Issues

Asynchronous initialization assumption conflict

The code in internal/core/graphics/wgpu_28.rs contains explicit comments stating:

// wgpu uses async here, but the returned future is ready on first poll on all platforms except WASM,
// which we don't support right now.

The Risk: On wasm, these futures may return Poll::Pending, causing the .expect() to panic. The current implementation assumes first-poll readiness, which is not guaranteed on WebAssembly.

Questions for the Slint Team

1. Was wasm intentionally excluded from femtovg-wgpu? We noticed the comments about async WGPU initialization not being supported on wasm, but in our testing it appears to work. Are there specific failure scenarios we might not have encountered?

2. Is there an existing plan for wasm support? We'd like to understand:

   • Whether wasm support for femtovg-wgpu is on the roadmap
   • If there are technical barriers we're not aware of
   • Whether our approach could be useful or if a different architecture is preferred

---

Related Files:

• internal/backends/winit/renderer/femtovg.rs
• internal/renderers/femtovg/images.rs
• internal/core/graphics/wgpu_28.rs
• internal/backends/winit/Cargo.toml (feature definition)