Re: As foundation for a large text editor web app, would WebGPU be quicker than the 2DContext in HTML Canvas?

I generally agree with Justin Novosad.

When comparing against a DOM implementation, if you re-implemented in Javascript all of the things a browser does for text editing,
You’ll negate all of the potential performance improvements that you thought you were getting. As you start out on the project, you will appear to be getting huge performance benefits, but as you re-implement all the things the browser does, your performance benefits will decrease to the point of ceasing to exist. And, you’ll be writing JavaScript instead of C++, so if you’re trying to do all the same things that a browser does (which you should be), you won’t be able to go as fast.
You’re likely to not be as correct as the browser’s native text editing code for all languages and scripts. Browsers have been in development for decades, and have had decade’s worth of bug fixes. Getting just static text to look correct is a challenging endeavor, and adding editing behaviors on top of that significantly increases the scope of the challenge.

When comparing against a 2D canvas implementation, there is no architectural reason why a WebGL or WebGPU implementation must go faster than a 2D canvas implementation for this kind of workload. Drawing 2D stuff, like a text editor does, is exactly what 2D canvas was designed for. If there is a workload that draws 2D stuff that executes significantly faster in WebGL/WebGPU than in 2D canvas, that would be a bug in 2D canvas, and should be fixed. As a browser engineer, I’d love details so I could investigate these claims further.

Text engines in browsers have been developed as general-purpose engines, designed to correctly and performantly display/edit any kind of text that appears on the internet. So, if that kind of workload is the kind of workload you are interested in, you’re going to have a tough time beating the browser by operating in Javascript inside the browser. However, if you have a domain-specific focus, like “I know all my users can clearly see the screen and they all only speak English and I’m going to force all the text to be displayed in a single font that doesn’t have any advanced layout features” then it seems clear that you could go faster than the browser. It’s just difficult to find a middle ground that is A) focused enough to be able to avoid enough work that the browser would be doing to improve performance beyond what the browser would be doing, and B) general enough that it’s useful for any reasonably-sized target audience.

—Myles

> On Jul 16, 2021, at 9:59 AM, Justin Novosad <junov@google.com> wrote:
> 
> Using canvas (2D or WebGL) for a text editor is a double-edged sword and I would not recommend it unless you are willing to invest a lot of effort into it.  The browser provides a lot of services that you get for free when you use HTML text.  Off the top of my head: text selection, accessibility support, page translation, text search (find in page), text shaping (ligatures, kerning, etc. see: https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html <https://harfbuzz.github.io/why-do-i-need-a-shaping-engine.html>), bidirectional text rendering (to support right-to-left languages, such as Arabic), emojis.  There's also a bunch of complex and useful layout algorithms that the browser provides for positioning text in a document. Also the web crawlers that update search engine indexes won't see text that is in a canvas.  Browser extensions that help people with visual impairments (text magnification, contrast enhancement, color corrections for the color blind) are unlikely to work correctly.  Most of these issues have workarounds, and I am sure there are third party libraries to help with many of these, but it is still a large undertaking.
> 
> Using a monospaced font helps avoid many of the complexities of text shaping. I think that may be what VSCode does. I guess it also depends on which of the above features you actually need to support.  For an editor you probably need at the very least to support text selection and text shaping.
> 
>     -Justin
> 
> 
> 
> On Wed, Jul 14, 2021 at 5:48 PM Kai Ninomiya <kainino@google.com <mailto:kainino@google.com>> wrote:
> +1. There are a number of examples out there that show using GL for editor rendering can be extremely efficient. You may only need WebGL 1.0, which has almost 100% reach; WebGL 2.0 or WebGPU will reach fewer users and will probably provide only small benefits - unless you have specific usecases for them (like if you have custom GPU text rendering algorithms or something).
> 
> -Kai (he/they)
> 
> 
> On Wed, Jul 14, 2021 at 4:27 AM Andrew Varga <grizzly33@gmail.com <mailto:grizzly33@gmail.com>> wrote:
> I think yes, using WebGL or WebGPU would be much faster than using the canvas 2D context if it's optimized properly.
> A good example is makepad, which is open source, written in Rust and uses WebGL:
> https://github.com/makepad/makepad <https://github.com/makepad/makepad>
> demo:
> https://makepad.dev/ <https://makepad.dev/>
> 
> I suspect the difference between WebGL and WebGPU will not be significant, at least initially while WebGPU is still very new.
> 
> On Wed, Jul 14, 2021 at 11:44 AM Eamon O'Tuathail <eamon.otuathail@gmail.com <mailto:eamon.otuathail@gmail.com>> wrote:
> There are a number of ways of creating a text editor in a web app:
> 1) using contenteditable 
> 2) using hidden text area (e.g. as seen with the Visual Studio Code's Monaco text editor)
> https://www.mozzafiller.com/posts/how-does-monaco-editor-enable-textediting-on-a-web-page <https://www.mozzafiller.com/posts/how-does-monaco-editor-enable-textediting-on-a-web-page>
> 3) using HTML Canvas
> 
> It seems for the larger text editor projects there is a trend to using the HTML Canvas-approach, mostly using the 2D Context with some use of WebGL. Here are some examples:
> 
> Visual Studio Code's use of canvas for the integrated terminal is described here:
> https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer <https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer>
> 
> The Register here writes about Google moving its editors to Canvas:
>   https://www.theregister.com/2021/05/13/google_warns_docs_rewrite_will/ <https://www.theregister.com/2021/05/13/google_warns_docs_rewrite_will/>
> Also Y Combinator has a very interesting thread discussing this:
>   https://news.ycombinator.com/item?id=27129858 <https://news.ycombinator.com/item?id=27129858> 
> 
> In particular in the Y Combinator discussion I note Microsoft's Tyiar states:
> -----------------
> "I wrote the terminal canvas renderers in VS Code that has been called out a few times here. Initially I implemented a canvas renderer using just a 2d context to draw many textures which sped things up "5 to 45 times"[1] over the older DOM renderer.
> Since then I moved onto a WebGL renderer[2] which was mostly a personal project, it's basically the first canvas renderer but better in every way since it works by organizing a typed array (very fast) and sending it to the GPU in one go, as opposed to piece meal and having the browser do its best to optimize/reduce calls. This was measured to improve performance by up to 900% in some cases over the canvas renderer"
> ----------------
> 
> I suspect WebGPU will be faster than WebGL, so my question is, would a text editor based on WebGPU be the absolutely fastest way of delivering a modern text editing experience in a web browser/PWA app?
> 
> Anyone got thoughts if this would be the case or real world (prototype) experience of this?
> 
> Eamon O'Tuathail
> https://clipcode.net <https://clipcode.net/>