Hacker News Reader

Comment by rrgok | Hacker News Reader

Perhaps I'm missing something, but why can't we render HTML directly onto the canvas in the browser? The parser is there, the layout engine is already implemented, and the calculation of box layout is already done. It should be doable without going in circles. If only the browser had a flag indicating which "surface" to render on.

I was looking at Glide Grid the other day, and it renders so fast, even with 1 million rows; it's somehow responsive. There should be an easier way to render HTML to canvas without resorting to low-level primitives. Why is canvas faster than the "regular" DOM renderer?

View on HN

But if all you want to do is render HTML then why use <canvas>?

I'm only speculating, but it doesn't seem surprising that regular DOM rendering logic - which has to handle approximately a bazillion different rules and special cases - is slower than a custom renderer written for a specific subset of HTML.

If you want to do any kind of text or diegetic UI in webgl, you are begging for DOM rendering to canvas (which is then sent to a texture)

As far as I remember, it's down to security concerns.

You can actually insert your HTML into a SVG foreignObject, and then drawImage() that onto your canvas. But your HTML-in-SVG document will need to load all its own resources, fonts, CSS etc.. which makes this process rather tedious.

Glide Grid is an amazing achievement I have to say!

You can have a fast DOM without canvas, but it requires creative thinking. DataGridXL also renders millions of cells, but it does not use canvas as its main renderer (https://www.datagridxl.com/demos/one-million-cells).

The way it works: only columns are their own DOM nodes. For browsers it's just too much to ask to re-render let's say (20rows*10cols) 200 DOM nodes while keeping scrolling at 60fps.

> it's just too much to ask to re-render let's say (20rows*10cols) 200 DOM

I don't think this is true with modern browsers and CSS. For a table, every cell and parents of the cells as much as possible, should be styled `contain: strict` and if possible, absolutely positioned.

It's still true. You might be able to get decent performance on a Macbook 3000 (doubtful even) but anything less than that, nope. That's why many grid components use canvas rendering. It would have been a lot easier for all these grid devs to work with DOM nodes if they could.

> That's why many grid components use canvas rendering

Many grid components were developed many years before modern compositors and the `contain` property.

Out of curiosity: What browsers did you test? Firefox performs magnitudes better in css benchmarks than Chrome, and I thought it is also better in handling large DOMs in general.

DataGridXL is used by 10 million end users. It's tested on all kinds of devices and browser combinations.

Browsers can handle AND update really large DOMs, but they still choke on doing all of these actions (repaint, reflow) WHILE SCROLLING, which is a different game.

You can use DOM-to-image (https://github.com/tsayen/dom-to-image).

Glide grid renders to canvas also.

Perhaps I worded it wrong: I meant to bring Glide Grid as an example how fast we can render millions of items to canvas.

It doesn't actually render millions of items though. It renders the visible viewport, something you can also do with pretty standard DOM virtualization techniques.

Reply on news.ycombinator.com