Comment by hnlmorg
1 day ago
This looks slick but I think you need a better way to market it.
The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is why Monaco (the editor widget behind VSCode) is a canvas. Why terminal emulators built with web technologies use canvas. And so on.
So I wouldn’t say the canvas part of the heading is a differentiator.
Edit: apologies, seems I was wildly wrong here. Please disregard the above.
> The 2D canvas part is the norm for anyone who wants performance. Working with the DOM becomes painfully slow and resource intensive the moment you add syntax highlighting, spell checking, and other visual chrome, to large documents.
This is wildly wrong. 2D canvas is consistently slower than letting the browser handle the rendering, so long as you avoid making the DOM too complex, and possibly monitor the viewport and only keep some of the content in the DOM at a time (though for most applications this practice is somewhere between harmful and not useful, and it definitely adds a lot of complexity).
> This is why Monaco (the editor widget behind VSCode) is a canvas.
It isn’t.
> Why terminal emulators built with web technologies use canvas.
Why on earth would you build with web technology, if you’re then going to use canvas? I can’t immediately think of any that match your description (though I have no doubt that in-browser ones using canvas exist).
> This is wildly wrong
You’re right. I’ve been experimenting with Monaco lots lately and could have sworn it used a canvas. But it doesn’t.
> 2D canvas is consistently slower than letting the browser handle the rendering, so long as you avoid making the DOM too complex, and possibly monitor the viewport and only keep some of the content in the DOM at a time (though for most applications it’s somewhere between harmful and not useful, and it definitely adds a lot of complexity).
Interesting. I’ve found the reverse to be true. But it sounds like this is human error on my part. (probably doesn’t help that I’ve had more experience building high performance GPU applications in Dx, SDL, and similar than I have building high performance web apps.
Thanks for the correction.
> Why on earth would you build with web technology, if you’re then going to use canvas? I can’t immediately think of any that match your description (though I have no doubt that in-browser ones using canvas exist).
You answered your own question.
And I do know of at least one written using the canvas. Because I wrote it. I’m now interested in how others work though.
Most in-browser terminal emulators just use plain old boring DOM, and ignore the issue of perfect columns. Some detect it and wrap offending characters in fixed-width spans. But the entire concept of columns is unsound, doesn’t work at all for a lot of scripts.
7 replies →
As far as I know, Monaco, the editor behind VS Code, does not use canvas. I noticed that Google Docs uses canvas, and that was the start of my project a year ago. I think that if I had used another context, like WebGL or WebGPU, it would have been much more performant, but it is really hard to render text and parse font files that way.
Anyway, I have gotten good enough results, and I don’t think normal usage will exceed the limits of the 2D canvas.