☂️ Intent to deprecate and remove the HTML renderer in Flutter Web

[yjbanov]

Document Link

https://flutter.dev/go/deprecate-html-renderer

What problem are you solving?

The HTML renderer is complex, underperforming, and limited in graphical expressivity compared to WebGL-based CanvasKit and Skwasm renderers. Flutter Web’s WebGL-based renderers matured to a point where the value provided by the HTML renderer no longer outweighs the maintenance costs, the developer-facing complexity (having to choose between multiple renderers and work around their limitations), and loss of focus on the WebGL renderers.

See the document for an expanded problem statement.

Tasks

The following tasks need to be completed before we begin the deprecation process:

• [web] replace current wasm image codecs with on-demand off-thread bundle #113713
  • [canvaskit] Determine if image is animated by reading its header and use Skia to decode in that case #151911
• optimized app loading (landed with the new bootstrap API)
• [web] sink pictures/platform views to the lowest available overlay #149863
• [web] Find an ergonomic solution for CORS images for CanvasKit and Skwasm #149843
• web build/run/test: log to terminal when user picks HTML renderer – that it's going away #154878
• web + html renderer + asserts enabled: log that HTML renderer is deprecated #154879

[Juliotati]

The link in "TBD" is 404.
Could it be that it will be available later?

[Novined]

Canvas renderer is awful. It's slow, even on high-end devices there are freezes, impossible to copy text even in text fields. Web renderer gives an opportunity to generate, not excellent, but ok-working solution

[yjbanov]

@Juliotati The go/ link is live now.

@Novined Text fields work identically between HTML and CanvasKit. I'm surprised there's a difference. We'd appreciate if you could file an issue explaining what's not working. Same about slowness. All indicators we have show that CanvasKit is faster in most scenarios. The only scenario where it's slower is in the presence of platform views, which is discussed in the proposal. We plan to focus on platform view optimization between now and the time we remove the HTML renderer.

[ImadBouirmane]

I'm not much close to your understanding but can you just give me a brief the dfiferent between Rendering by HTML or by CanvasKit.
Look to hear from you.

[yvrez]

Go for it. Webgl rendering + wasm is the way to go & we need the team to focus on a single performant & futur proof renderer.

[ditman]

I'm not much close to your understanding but can you just give me a brief the dfiferent between Rendering by HTML or by CanvasKit. Look to hear from you.

Check the document that @yjbanov linked at the beginning of the thread; I think it summarizes well the pros/cons of each renderer.

[dxvid-pts]

Sunsetting the html renderer would be very problematic for one of our projects as the canvaskit renderer is still buggy in platform view scenarios.

An example: #143747. We also experience various other issues when platform views are present. For example

• Firefox is flickering until the platform view is removed from the scene
• Rendering issues on old safari versions (Safari version 14).

These issues are not present when using the html renderer.

[gildaswise]

I'm still not comfortable with the CORS situation. Is the Flutter team really expecting everyone to give up Image.network working with any image and pivot to using platform views with fixed sizes? The proxy solution isn't that good either.

For context, I'm developing deck.blue, a Bluesky client which means that I will never "own" the images displayed and would rely on them turning on CORS. And that also wouldn't work 100% due to how federation works and soon there will be media hosted outside of their CDN. What then? Should I just use proxies and have to pay for that?

[SaadArdati]

The HTML renderer still performs better than CanvasKit in certain browsers like WebKit (any iOS browser) & Safari.

My reference is developing this Flutter website https://hyperzones.hyperdesigned.dev/. It performed extremely poorly under 10fps on CanvasKit, and peforms significantly better (but still not great) on WebKit. So we force-enable HTML when building and deploying it.

I would not remove HTML Renderer.

[r3flow]

If WebGL or Skwasm works well and is stable in the iOS browser, you can remove the HTML renderer. If not, then no.