A visual comparison of HTML-in-Canvas vs rasterizing DOM to a canvas texture (side-by-side below, compare average capture times) Existing approaches to pull web content into canvas are slow and lossy: - Animations glitch, or don't play at all - CSS replication is imprecise - Clogs up the main thread,... other animations lag HTML-in-Canvas (texElementImage2D) lets the browser's own compositor map CSS layouts, animations, and transitions precisely into canvas/WebGL textures — one native call instead of thousands of JS style reads. It's currently available behind an experimental Chrome flag. Really cool, and I can't wait for it to become mainstream.show more

Well 30ms is still slow isn’t it ? Is there a way to run the canvas off thread and instead transfer the canvas over a worker instead ?

It is, yeah! Plenty of optimisations you could add to speed things up, this is more just a quick comparison of the two approaches running on my fairly mid laptop My understanding is that the html in canvas approach already uses an optimal route to grab the pixel data directly from the browser’s pipeline A lot of that bloat likely comes from the various CSS animations and reflows The pretext library might actually be of use here too

There's a link to the actual demo here (toggle in top left corner)

@Samsyyyy On MacBook M1 Max, 32 GB is 0.2-0.4ms. So performance is good on mid-high devices. I do have one question: Do you use polyfill? because I'm running html-in-canvas example inside of regular Chrome.

@Samsyyyy Yeah I need a better laptop haha 😂 Poor GPU probably doesn't help. No polyfill at the moment, though it should disable the html-in-canvas option if the appropriate flag isn't set - do you get the "Browser native" button in top left?

By the end of 2026, every React app: <html> ... <canvas> <html> ... </html> </canvas> ... </html>

95% of them probably just magnifying lenses or text swirling around too! There’s a lot more potential for what this can do tbh, I think the examples are only scratching the surface

It’s still a way off full adoption too though, still plenty of eg security considerations, feature optimisations

@gfxprogrammer FWIW I took a look at this not too long ago and reached very different conclusions. The way it's designed, it can't really act as a proper UI layer.

The elements can still trigger events?

Like onclick etc? I believe so - they're real DOM elements. I know there's some issues with clickthrough, hover using the canvas approach but it's still early in development. But yeah the idea is that eventually it's as usable as true DOM elements but rendered within canvas

Very interesting feature...

This is going to solve a LOT of problems. More than just render speed.

very nice

Okay, but I’m not gauging performance off of multiple resizing, and I don’t know anyone else who is

It's not a practical example, more exploring the best way to benchmark the techniques html-in-canvas would be replacing. Also if you're trying to run animations or interactivity within that canvas, you'd need low lag regardless.

What are the stats of this (memory and cpu usage)?

Relatively minimal, it's not a particularly intensive process, the newer method simply hooks into the data the browser already prepares for display anyway, so should run smoother.

I'd love to see the web is hardware accelerated with GPU instead of rendering it via CPU. My 16 y.o laptop can handle GLSL on WebGL really well. And yeah as expected, doing the 2D canvas on it really puts it to a hell LOL.

i’m so happy! skeumorphism can return

Love this side by side