TL;DR

Skwasm currently has a presentation path that is fast on Chromium but impractical on Safari and Firefox because final frame presentation depends on OffscreenCanvas.transferToImageBitmap / ImageBitmapRenderingContext.transferFromImageBitmap. This issue now tracks the design-doc discussion for making Skwasm presentation pluggable so Chromium can keep the current fast ImageBitmap backend while Safari/Firefox can use a direct visible-canvas or stabilized multi-surface backend.

Design document status

Per the Flutter design document process, I moved the long-form proposal into a public Flutter design document draft and am keeping this issue as the tracking/context issue.

Design document link: https://docs.google.com/document/d/1LdznORnY3yqE9Pp00ybmKm-ghN1Z9-Ko2nwlirJAe_w/edit?usp=sharing

Suggested design doc title: Skwasm Cross-Browser Presentation Backends for Safari and Firefox (PUBLICLY SHARED)

The design doc label may need to be added by someone with permissions.

Core problem

Flutter WebAssembly currently works best on Chromium-based browsers. Safari and Firefox either do not support Flutter's Wasm renderer reliably or hit severe presentation-path performance problems.

The practical blocker appears to be the browser presentation path around OffscreenCanvas, transferToImageBitmap, and/or transferFromImageBitmap. A Flutter-side presentation abstraction could allow Skwasm to select a backend based on browser capability and observed browser behavior rather than relying on one presentation path everywhere.

Relevant areas: Skwasm presentation, Flutter web engine, Safari/Firefox compatibility, renderer architecture.

Related links

• Flutter Wasm docs: https://docs.flutter.dev/platform-integration/web/wasm
• Flutter web renderer docs: https://docs.flutter.dev/platform-integration/web/renderers
• Existing multi-surface / ImageBitmap tracking issue: [web] Remove multi-Surface rendering for Firefox and Safari once they have efficient support for transferToImageBitmap/transferFromImageBitmap #145420
• Firefox bug 1788206: https://bugzilla.mozilla.org/show_bug.cgi?id=1788206
• WebKit bug 234920: https://bugs.webkit.org/show_bug.cgi?id=234920
• WebKit bug 267291: https://bugs.webkit.org/show_bug.cgi?id=267291

Proposal context

At a high level, the design document explores:

• adding a narrow SkwasmPresentationBackend abstraction
• preserving the current ImageBitmap backend for Chromium
• evaluating direct visible-canvas presentation for Safari/Firefox
• evaluating whether the existing multi-surface strategy should become an official Safari/Firefox-compatible backend
• adding benchmarks and an experimental override before changing defaults
• keeping existing CanvasKit fallback behavior for browsers that cannot run Skwasm